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SECTION 1 
SUMMARY OF INITIALIZATION 



Multics initialization, as described in this SDN, can be 
thought of as divided into the following parts: 

* Hardware and PL/1 Environment initialization (Collec- 
tion 0) 

* Page Control initialization (Collection 1 service pass) 

* Boot load Command Environment (bee) (Collection 1 multi- 
ple passes) 

* Crash Handler (toehold) 

* File System initialization (Collection 2) 

* Outer ring Environment initialization (Collection 3) 

The parts listed before collection 2 are collectively called 
" Boot I oad Mu 1 1 i cs . " 

A collection is simply a set of initialization routines 
that are read in and placed into operation as a unit to perform a 
certain set, or a certain subset t of the tasks required to 
initialize a portion of the Multics supervisor. Each collection 
consists of a distinct set of programs for reasons discussed 
throughout this SDN. Even though each collection mostly exists 
to perform a particular set of functions, they are normally 
referred to by their number (which have only historical signifi- 
cance) rather than the name of their function. 

Initialization may also be thought of as having three 
separate functions: 

Bringing up the system 

This role is obvious. The description of this role 
follows along the functions needed to perform it. Each 
portion of initialization runs, utilizing the efforts 
of the previous portions to build up more and more 
mechanism until service Multics itself can run. 

Providing a command environment before the file system is 
activated from which to perform configuration and disk 
maintenance functions 
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Providing an environment to which service Multics may crash 
which is capable of taking a dump of Multics and 
initiating recovery and reboot operations 

These last two functions are the role of boot load Multics 
(bee). They take advantage of the fact that during 
initialization an environment is built that has certain 
facilities that allow operations such as disk manipulation to 
occur but it is an environment in which the disks themselves are 
not yet active for storage system operations. This environment, 
at an intermediate point in ini t ial ization, forms the boot load 
command environment (bee). 

The boot load command environment is saved before further 
initialization operations occur. When service Multics crashes, 
service Multics is saved and this bee "crash" environment is 
restored, This safe environment can then examine or dump the 
service Multics image and perform certain recovery and restart 
operations without relying on the state of service Multics. 

HARDWARE AjvjQ EU± ENVIRONMENT INITIALISATION 

The purpose of collection is to set up the pl/1 
environment and to start collection 1. It has a variety of 
interesting things to perform in the process. First of all, 
collection must get itself running. When Multics is booted 
from BOS, this is an easy matter, since BOS will read in the 
beginning of collection 0, leaving the hardware in a known and 
good state and providing a description of the configuration 
( conf ig_deck) around. When not booted from BOS, that is, when 
booted via the I0M boot function, collection has the task of 
getting the hardware into a good and known state and finding out 
on what hardware it is working. Once collection has set up the 
hardware, it can load collection 1 into memory. Collection 1 
contains the modules needed to support programs written in pl/1; 
thus, this loading activates the pl/1 environment. After this 
time, more sensible programs can run and begin the true process 
of initialization. The result of this collection is to provide 
an environment in which pl/1 programs can run, within the 
confines of memory. 

PAGE CONTROL INITIALIZATION 

The main task of collection 1 is to make page control 
operative. This is necessary so that we may page the rest of the 
initialization programs (initialization programs all have to fit 
into memory until this is done). The initialization of page 
control involves setting up all of the disk and page control data 
bases. Also, the interrupt mechanism must be initialized. The 
result of this collection is to provide an environment in which 
i/o devices may be operated upon through normal mechanisms (i.e., 
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via page faults or direct calls to the standard device control 
modules) but in which the storage system is not active. At the 
final end of collection 1, this environment becomes paged, using 
a special region of the disks (the hardcore partition) so that 
the storage system is not affected. 

Collection 1 can be run multiple times. The effect of 
making a pass through collection 1 is to set up the device tables 
(and general configuration describing tables) to reflect a new 
configuration. The various passes of collection 1 are the key to 
the operation of bee. There are several times when the running 
of collection 1 is necessary. It is necessary when we first 
start up, to allow accessing the hardware units "discovered" by 
collection 0. Once the correct configuration is determined via 
bee activities, collection 1 must be re- run to allow all of the 
devices to be accessible during the rest of initialization and 
Multics service proper. Finally, when the crash environment is 
restored (see below), another pass must be made to provide 
accessibility to the devices given the state at the time of the 
crash. 

FILE SYSTEM INITIALIZATION 

With paging active, collection 2 can be read into a paged 
environment. Given this environment, the major portion of the 
rest of initialization occurs. Segment, directory and traffic 
control are initialized here, making the storage system accessi- 
ble in the process. The result of this collection is an 
environment that has active virtually all hardcore mechanisms 
needed by the rest of Multics. 

OUTER Elm. ENVIRONMENT INITIALIZATION 

Collection 3 is basically a collection of those faci li ties 
that are required to run in outer rings. In particular, it 
contains the programs needed to provide the initializer's ring 
one environment, especially the code to perform a reload of the 
system (especially the executable libraries). After the execu- 
tion of this collection, the Initializer enters into a ring one 
command environment, ready to load the system ( if necessary) and 
start up the answering service. (Activities performed from ring 
one onward are not covered in this SDN. ) 

B00TL0AD COMMAND ENVIRONMENT ( B C EJ 

The boot load command environment is an environment that can 
perform configuration and disk management functions. It needs to 
be able to support i/o to devices in a pl/1 environment. Also, 
since bee must be able to operate on arbitrary disks, it must be 
capable of running before the storage system is active. Thus, it 
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is equivalent to the collection 1 environment before the environ- 
ment becomes paged. In this environment built by a special run 
of collection 1, a series of facilities provides a command 
environment that allows pl/1 programs to run in a manner similar 
to their operation in the normal Multics programming environment. 

CRASH HAN PI E R IT<5£HQLP) 

When Multics has crashed, Multics is incapable of 
performing the types of analysis and recovery operations desired 
in its distressed state. Thus., a safe environment is invoked to 
provide these facilities. Since bee is capable of accessing 
memory and disks independently of the storage system (and the 
hardcore partitions) , it becomes the obvious choice for a crash 
environment. When Multics crashes, bee is restored to operation. 
Facilities within bee can perform a dump of Multics as well as 
start recovery and reboot operations. The crash environment 
consists of the mechanisms needed to save the state of Multics 
upon a crash and to re- setup the boot load command environment. 
These mechanisms must work in the face of varying types of system 
failures; they must also work given the possibility of hardware 
reconfiguration since the time the safe environment was saved. 
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SECTION 2 



COLLECTION 



Collection in Boot load Multics is an ensemble of ALM 
programs capable of being booted from BOS or the IOM, reading 
themselves off of the boot tape, loading tape firmware if needed, 
setting up an I/O and error handling environment, and loading 
col lection 1 . 

Collection is organized into two modules: 
bootload_tape_ label , and bound_bootload_0, The first is an MST 
label program designed to read the second into its correct memory 
location, after being read in by the IOM boot load program, The 
second is a bound collection of ALM programs. bound_bootload_0 
takes extensive advantage of the binder's ability to simulate the 
linker within a bound unit, The programs in bound_bootload_0 use 
standard external references to make intermodule references, and 
the binder, rather than any run-time linker or pre- 1 inker, 
resolves them to TSR- relative addresses. Any external references 
(such as to the config deck) are made with explicit use of the 
fact that segment numbers for collection programs are fixed at 
assembly time. 

PE TT ING STARTED 

boot I oad_tape_ label is read in by one of two means. In 
native mode, the IOM or HOC reads it into absolute location 30, 
leaving the PCW, DCW's, and other essentials in locations 
through 5. The I IOC leaves an indication of its identity just 
after this block of information. 

In BOS compatibility mode, the BOS BOOT command simulates 
the IOM, leaving the same information. However, it also leaves a 
config deck and flagbox (although bee has its own flagbox) in the 
usual locations. This allows Boot load Multics to return to BOS 
if there is a BOS to return to. The presence of BOS is indicated 
by the tape drive number being non-zero in the idew in the "IOM" 
provided information. 



2-1 



AN70-01 



The label overlays the interrupt vectors for the first two 
ISM's, Because the label is formatted as a Multics standard tape 
record, it has a trailer that cannot be changed. This trailer 
overlays the interrupt vectors for channels B9 and BIO. Without 
a change in the label format, the boot load tape controller cannot 
use either of these channels as a base channel , because the label 
record wipes out the vectors that the IOM boot load programs sets 
up. This prevents control from transferring to the label 
program. 

The label program first initializes the processor by 
loading the Mode Register and the Cache Mode Register., and 
clearing and enabling the PTWAM and the SDWAM. It then reads all 
of bound_bootload_0 off the tape. This action places the toehold 
and bootload_ear ly_dump into their correct places in memory, in 
as much as these two modules are bound to be the first two 
objects in bound_bootload_0. If this is successful, it transfers 
to the beginning of bootload_abs_mode through sn entry in the 
toehold. (This entry contains the address of bootload_abs_mode, 
via the linking performed by the binder.) This program copies 
the template descriptor segment assembled into template_slt_ to 
the appropriate location, copies int_unpaged_page_ tables and 
unpaged_page_ tables to their correct locations, loads the DSBR 
and the pointer registers, enters appending mode, and transfers 
to bootload_0. 

PROGRAMMING JJN[ COLLECTION fi 

Collection programs are impure assembly language pro- 
grams. The standard calling sequence is with the tsx2 instruc- 
tion. A save stack of index register 2 values is maintained 
using id and di modifiers, as in traffic control. Programs that 
take arguments often have an argument list following the tsx2 
instruction. Skip returns are used to indicate errors. 

The segment bootload_ inf o, a cds program, is the repository 
of information that is needed in later stages of initialization. 
This includes tape channel and device numbers and the like. The 
information is copied into the collection 1 segment sys_boot_ info 
when collection 1 is read in. 



M QPULE DESCRIPTIONS 

boot I oad abs mode. aim 

As mentioned above, bootload_abs_mode is the first program 
to run in bound_bootload_0. The label program locates it by 
virtue of a tra instruction at a known place in the toehold 
(whose address is fixed)j the tra instruction having been fixed 
by the binder. It first clears the memory used by the Collection 
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data segments, then copies the template descriptor segment , 
int_ unpaged. page_ tables and unpaged. page_ tables from 
template_slt_ . The DSBR is loaded with the descriptor segment 
SDW, the pointer registers are filled in from the ITS pointers in 
template_slt_, and appending mode is entered. bootload_abs_mode 
then transfers control to bootload_0Sbegin, the basic driver of 
collection zero initialization. 

boot load O.alm 

bootload_0's contract is to set up the 1/0, fault., and 
console services,. and then load and transfer control to collec- 
tion 1. As part of setting up the 1/0 environment, it must load 
tape firmware in the boot load tape MPC if BOS is not present. 
bootload_0 makes a series of tsx2 calls to set up each of these 
facilities in turn. It calls boot load_ ioSpreinit to interpret 
the bootload program left in low memory by the I 0M/ I I OCY I OX, 
including checking for the presence of BOS; 
bootload_f lagboxSpreinit to set flagbox flags according to the 
presence of BOS; bootload_f aultsS ini t to fill in the fault 
vector j boot I oad_s 1 1_ managers in it_ sit to copy the data from 
template_slt_ to the SLT and name_ table; bootload_ io$ ini t to set 
up the 1/0 environment; boot I oad_ consoles ini t to find a working 
console and initialize the console package; boot I oad_ loaders ini t 
to initialize the MST loading package; bootload_tape_f wSboot to 
read the tape firmware and load it into the bootload tape 
controller; boot I oad_ loaders I oad_ col lection to load Collection 
1.0; bootload_ loaders? in ish to copy the MST loader housekeeping 
pointers to their permanent homes; and bootload_l inkerSprel ink to 
snap all links in Collection 1.0. 

Finally, the contents of bootload_ inf o are copied into 
sys_boot_ info. Control is then transferred to bootload_1 . 



The firmware sgUectiPh, 

As described below under the heading of 
"bootload_tape_f w. aim" j tape firmware must be present on the MST 
as ordinary segments. It must reside in the low 256K, because 
the MPC's do not implement extended addressing for firmware 
loading. The tape firmware segments are not needed after the MPC 
is loaded, so it is desired to recycle their storage. It is 
desired to load the MPC before collection 1 is loaded, so that 
backspace error recovery can be used when reading the tape. The 
net result is that they need to be a separate collection. To 
avoid destroying the old correspondence between collection num- 
bers and sys_ inf o$ ini t ial izat ion_ state values, this set exists as 
a sub- co I lection. The tape firmware is collection 0.5, since it 
is loaded before collection 1. The segments in collection 0.5 
have a fixed naming convention. Each must include among its set 
of names a name of the form "f wid. Tnnn" , where "Tnnn" is a four 
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character controller type currently used by the BOS FWLOAD 
facility. These short names are retained for two reasons. 
First, they are the controller types used by Field Engineering. 
Second, there is no erase and kill processing on input read in 
this environment j so that short strings are advantageous. Note 
that if the operator does make a typo and enters the wrong 
string, the question is asked again. 



boot load console. aim 

boot I oad_ console uses 
initialization entry, init, 
I0M. This is done by first 
left us one, or, if not, by 
comment to each channel in 



bootload_io to do console I/O. Its 

finds the console on the boot load 

looking in the config deck, if BOS 

trying to perform a 51 (Write Alert) 

turn). Only console channels respond 



to this command. When a console 
is used to determine the model. 



is found, a 57 (Read ID) command 



The working entrypoints are write, write_nl, write_alert, 
and read_line. write_.nl is provided as a convenience. All of 
these take appropriate buffer pointers and lengths. Read_line 
handles timeout and operator error statuses. 

There are three types of console that boot I oad_ console must 
support. The first is the original EMC, CSU6001 . It requires 
all its device commands to be specified in the PCW, and ignores 
IDCW's. The second is the LCC, CSU6601 . It will accept commands 
in either the PCW or IDCW's. The third type is the I PC- CONS- 2. 
In theory, it should be just like the LCC except that it does NOT 
accept PCW device commands. Whether or not it actually meets 
this specification has yet to be determined. 

To handle the two different forms of I/O (PCW commands 
versus IDCW's), boot I oad_ console uses a table of indirect words 
pointing to the appropriate PCW and DCW lists for each operation. 
The indirect words are setup at initialization time. The LCC is 
run with IDCW's to exercise the code that is expected to run on 
the IPC-CONS-2. 

boot I o ad dsea.alm 

bootload_dseg' s task is to prepare SDW's for segments 
loaded by boot I oad_ loader, the collection zero loader. 
bootload_dseg$make_sdw takes as an argument an sdw_info structure 
as used by sdw_util_, and constructs and installs the SDW. The 
added entrypoint boot I oad_dseg$ make_core_.pt w is used by 
boot I oad_ loader to generate the page table words for the unpaged 
segments that it creates. 
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frootload early dump .aim 

When an error occurs during early initialization, 
bootload_early_dump is called. It is called in three ways. 
First, if bootload. error is called for an error (as opposed to a 
warning) , this routine is called. Secondly, if a crash should 
occur later in initialization (after collection 0) but before the 
toehold is set up (and bee running), the toehold will transfer 
here. Third, the operator can force a transfer to this routine 
through processor switches any time up until col lect_f ree_core 
runs. (This includes while bee is running.) This is done by 
force executing a "tra 30000o" instruction. 

bootload_ear ly_dump starts by reestablishing the collection 
environment ( masked, pointer registers appropriately set, 
etc. ) . It then uses boot I oad_ conso I e to ask. for the number of a 
tape drive on the bootload tape controller to use for the dump. 
When it gets a satisfactory answer, it dumps the first 512k of 
memory (that used by early initialization and bee), one record at 
a time, with a couple of miscellaneous values used by 
read_ear ly_dump_tape (which constructs a normal format dump). If 
an error occurs while writing a record, the write is simply 
retried (no backspace or other error recovery). After 16 
consecutive errors, the dump is aborted, a status message 
printed, and a new drive number requested. 

bootload error, aim 

boot I oad_ error is responsible for all the error messages in 
collection 0. It is similar in design to page_ error . aim; there 
is one entrypoint per message, and macros are used to construct 
the calls to bootload_f orml ine and bootload_console. 
bootload_ error also contains the code to transfer to 
bootload_ear ly_dump. There are two basic macros used: "error", 
which causes a crash with message, and "warning", which prints 
the message and returns. All the warnings and errors find their 
parameters via external references rather than with call parame- 
ters. This allows tra's to boot I oad_ error to be put in error 
return slots, like: 

tsx2 read_word 

tra bootload_error$console_ error 

" error, status in 

" boot I oad_ consoles I ast_ err or _ status 
... " normal return 

Warnings are called with tsx2 calls. 
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boot I oad faults. aim 

boot load_ faults sets up the segment fault_ vector. All 
faults except timer runout are set to transfer to 
boot I oad_ error* unexpected_f ault. All interrupts are set to 
transfer control to bootload_error$unexpected_ interrupt since no 
interrupts are used in the collection zero environment. The same 
structure of transfers through indirect words that is used in the 
service fault environment is used to allow individual faults to 
be handled specially by changing a pointer rather than 
constructing a different tra instruction (also, instructions do 
not allow "its" pointers within them). The structure of the 
scu/tra pairs (but not the values of the pointers) formed by 
bootload_faults is that used by the rest of initialization and 
service. 

boot 1 oad _f laabox .aim 

bootload_f lagbox zeroes the bee f lagbox. It also zeroes 
the cold_disk_mpc flag when BOS is present for historical 
reasons. Various values &re placed in the f lagbox that no one 
looks at. This program is responsible for the state of the BOS 
toehold as well. It copies the BOS entry sequences into the bee 
toehold and sets the bee entry sequence into the BOS toehold for 
the sake of operators who enter the wrong switches. 

boot I oad formline.alm 

This program is a replacement for the BOS erpt facility. 
It provides string substitutions with ioa„-like format controls. 
It handles octal and decimal numbers, BCD characters, asci i in 
units of words, and ACC strings. Its only client is 
boot I oad_ err or , who uses it to format error message. The BCD 
characters are used to print firmware ID'S found in firmware 
images, Its calling sequence is elaborate, and a macro, 
"formline", is provided in bootload_forml ine. incl . aim 

boot \ o .gd i nf o ■ eds 

The contents of this segment are described under data 
bases. 

boptload tOi^lm. 

bootload_io is an io package designed to run on IOM's and 
I IOC's. It has entrypoints to connect to channels with and 
without timeouts. It always waits for status after a connection. 
It runs completely using abs mode i/o, and its callers must fill 
in their DCW lists with absolute addresses. This is done because 

2-6 AN70-01 



NSA IOM's do not support rel mode when set in PAGED mode, and 
there is no known way to find out whether an IOM is in paged 
mode. Under normal operation the config card for the I CM is 
available to indicate whether the IOM is in paged mode or not, 
relieving this difficulty. 

The preinit entrypoint is called as one of the first 
operations in collection 0. Besides setting up for i/Oj it 
copies and determines from the I0M/I IOC/B0S provided boot info 
the assume. config. deck (BOS present) flag and the system. type 
value. 



bo ot load I inker .aim 

boot load. I inker is responsible for snapping all links 
between collection one segments. It walks down the LOT looking 
for linkage sections to process. For each onej it considers each 
link and snaps it. It uses boot load_s I t_ managers get_seg_ptr to 
find external segments and implements its own simple definitions 
search. 



boot load loader .aim 

boot l oad_ loader is the collection zero loader (of collec- 
tions 0.5 and 1). It has entrypoints to initialize the tape 
loader (init), load a collection ( I oad_ col lection) , skip a 
collection ( skip_ col lection) , and clean up (finish). The loader 
is an aim implementation of segment. I oader . pi 1 , the collection 1 
loader. It reads records from the mstj analyzes them, splitting 
them into sit entries, definitions and linkage sectionSj and 
segment contents. Memory is obtained for the segment contents 
using allocation pointers in the sit. Page tables are allocated 
for the segment within the appropriate unpaged. page. tables seg- 
ment. When proper^ the breakpo in t^ page is added as another page 
to the end of the segment. Definitions and linkage sections are 
added to the end of the proper segments (ai.linkagej wi_ linkage, 
ws.linkage, as.linkage). The loader has a table of special 
segments whose segment numbers (actually ITS pointers) are 
recorded as they are read in off of the tape. These include the 
hardcore linkage segments, needed to load linkage sections, 
definitions., and others. The loader maintains its current 
allocation pointers for the linkage and definitions segments in 
its text. bootload. loaderSf inish copies them into the headers of 
the segments where segment. I oader expects to find them. 

boot load sit_manager,gilm 

boot load. sit. manager is responsible for managing the Seg- 
ment Loading Table (SLT) for collection zero. It has three 
entries. boot 1 oad. sit. managers init. sit copies the SLT and name 
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table templates from template_slt_ to the sit and name_table 
segments. boot I oad_ si t_ managers bui I d_ entry is called by 
boot I oad_ loader to allocate a segment number and fill in the SLT 
and name table from the information on the MST. 
boot I oad_s 1 1_ managers get_seg_ptr is called by bootload_ I inker to 
search the SLT for a given name. It has imbedded in it a copy of 
hash_index_ used to maintain a hashed list of segment names 
compatible with the list for slt_manager in further collections. 

boot I oad tape fw.alm 

bootload_tape_f w is responsible for loading the boot I oad 
tape MPC. It begins by loading collection 0.5 into memory with a 
call to boot I oad_ loaders I oad_ co I lection. By remembering the 
value of sit. last_ init_ seg before this call, bootload_tape_fw can 
tell the range Tn segment numbers of the firmware segments. 
Firmware segments are assigned init_seg segment numbers by 
boot I oad_ loader , but are loaded low in memory, for reasons 
described above. bootload_tape_f w then determines the correct 
firmware type. If bootload_ inf o specifies the controller type., 
then it proceeds to search the SLTE names of the firmware 
segments for the appropriate firmware. If bootload_ inf o does not 
specify the firmware type, then bootload_tape_f w must ask the 
operator to supply a controller type. This is because there is 
no way to get a controller to identify itself by model. 

Each of the firmware segments has as one of its SLTE names 
(specified in the MST header) the six character MPC type for 
which it is to be used. bootload_tape_fw walks the sit looking 
for a firmware segment with the correct name. If it cannot find 
itj it re- queries (or queries for the first time) the operator 
and tries again. 



Having found the right firmwarej 
sequence is initiated to boot the 
segments" SOW s are zeroed, and the 
restored to their pre-col lection- 0. 5 
then returns. 



the standard MPC boot I oad 

tape MPC. The firmware 

sit allocation pointers 

values. bootload_tape_f w 



template sit , aim 

This aim program consists of a group of involved macros 
that generate the SLTE's for the segments of collection zero. It 
is NOT an image of the segment sit, because that would include 
many zero SLTE's between the last sup seg in collection zero and 
the first init seg. Instead, the init seg SLTE's are packed in 
just above the sup segs, and boot I oad_s I t_ managers ini t_slt 
unpacks them. It also contains the template descriptor segment, 
packed in the same manner, and the template name table. The 
initial contents of int_unpaged„page_ tables and 
unpaged_page_ tables are also generated. Also present are the 
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absolute addresses, lengths, and pointers to each of the collec- 
tion segments for use elsewhere in bound_bootload_0. 
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SECTION 3 



COLLECTION 1 



The basic charter of collection 1 is to set up paging, 
fault handling, as well as various data bases needed for paging 
and other like activities. Collection 1 can run multiple times, 
for various reasons. 

SUMMARY SE COLLECTION 1 PASSES 

The first run through collection 1 is known as the "early" 
pass which is described below. It is a run in which we are 
restricted to work within 51 2K and in which only the rpv is 
knownj in fact, it is this pass which finds the rpv and the 
config deck. If BOS is present, this pass is not needed. The 
end of this pass is the arrival at "early" command level, used to 
fix up the config deck, in preparation for the "boot" pass. 

The second pass, which is known as "boot load Multics 
initialization", also runs only within 512K. It, however, has 
knowledge of all disks and other peripherals through the config 
deck supplied either by BOS or the early initialization pass. 
This pass is made to generate a crash- to-able system that can be 
saved onto disk for crash and shutdown purposes. After the crash 
handler (this image) is saved, the boot load Multics "boot" 
command level can be entered. This level allows the booting of 
Multics service. After Multics has shut down, a slight variant 
of this pass, the "shut" pass, is run in a manner similar to that 
for the "crash" pass, described below. 

The third pass (which actually comes after the fourth) is 
another run of boot load Multics initialization performed after 
Multics has crashed. This pass is made to re- generate various 
tables to describe the possibly different configuration that now 
exists after having run Multics. Boot load Multics "crash" 
command level is then entered. 

The fourth pass through collection 1 is called "service 
initialization", which runs using all memory and devices. The 
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result of this pass is suitable for running the later collec- 
tions, and bringing up service. 

The "early" pass creates a safe environment consisting of a 
set of programs in memory and a synthesized conf ig deck, that 
describes known hardware. This is saved away to handle crashes 
during the "boot" pass. If the "boot" pass fails, the toehold 
restores this earlier saved environment which then runs a 
"re_early" pass. This is really a normal pass, but using the 
saved away config deck of known good hardware. The "re. early" 
pass comes back to an "early" command level to allow the operator 
to fix the deck or hardware. 

When the "boot" pass succeeds, it also saves a good memory 
image and the now confirmed site config deck. After the "boot" 
pass saves this image, the "boot" command level is entered and 
eventually it boots Multics, running the "service" pass. If this 
fails, the toehold restores the saved image. A "bce_ crash" pass 
then runs. This is a normal pass but one in which the saved 
config deck is used. This pass is run on the assumption that, 
either a bee command died and the operator may now examine it, or 
that the "service" pass found a problem. The "bce_crash" level 
allows the operator to fix things. 

Once the boot of service Multics completes collection 1, a 
crash or shutdown will invoke the toehold to restore bee. This 
time, however, the current config deck is used to utilize any 
reconfigurations that have occured, bee will come to the "crash" 
or "boot" command levels. 

We'll start by looking at the basic initialization pass, 
that used to come to the normal ("boot") bee command level. 

NQRMAL CpSQT) PASS 

The sequence of events in a normal initialization pass is 
given here. As of the time of the start of a normal 
initialization pass, the config deck has been found, either by 
BQS or the early initialization pass. All other data bases 
besides sys_boot_ inf o and sys_info set or created during previous 
initialization passes have been deleted. The pass starts with 
saving certain attributes, such as free core extents, for later 
restoration at the end of the pass (before running another). 

scs_and_clock_ init fills in the initial scs (system config- 
uration segment) data from the config deck. This is information 
on the processors and the memory controllers. 

get_io_segs, iom_data_ init, ocdcm_$ init_al l_consoles, and 
scas_init are run to set up the disk_seg, pvt, iom_data, 
ioi_data, oc_data and the system controller addressing segment. 
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tc_init initializes tc_ data's apte and itt lists. 

init_sst generates the sst and core map appropriate for the 
pass. This is the last real memory allocation. After this time, 
allocation of memory based upon the data in the sit is 
deactivated. The remaining tables either have memory already 
allocated for them or are generated paged, once paging is 
started. announce_chwm announces memory usage. 

init ial ize_f aults$ interrupt. init initializes the interrupt 
vector. With iom_data and oc_data set upj this permits ocdcm_ to 
be used for console I/O. The interrupt mask is opened with a 
call to pmut$set_mask. 

The basic command environment facilities (1/0 interfaces 
and a free area) are set up in a call to init_bce. <BCE is an 
acronym for Bootload Command Environment). This allows programs 
that query the operator to do so in a more friendly fashion than 
raw calls to ocdcm_ . Further descriptions of bee facilities 
follow later. 

load_disk_mpcs runs (only during a "boot" pass and only 
when we do not have BOS present) to make sure that all disk mpes 



Wilcfl wc uu i iu *» nave uuu j^i cqciiv/ 

have firmware active within them. 



init_pvt, read_disk$ ini t and init_root_vols together have 
the net effect of setting up disk and page control. No segments 
are paged at this time., though, except for rdisk_seg. Once we 
reach here, we know that the config deck describes a set of 
hardware sufficient (and valid) enough to reach command level and 
so we save the config deck as safe_ conf ig_ deck. 

establ ish_temp_segs maps the bootload paged temp segments 
onto the reserved area for them in the "bee" partition, 
f ind_f i le_part i t jon maps the bee file system area 
( bootlpad_f i le_part i t ion) unto the "file" partition. 

load_mst$ ini t_ commands maps the pagable bee programs onto 
the areas of disk in which they were read by load_mst earlier. 

If this is a "early" or "boot" pass., this environment is 
saved and the toehold setup to invoke it. This is done by 
ini t_ toehold. The "early" pass saves the entire environment the 
"boot" pass simply saves the safe_ conf ig_ deck so determined by 
this pass. 

bce_get_to_command_ level can now be called to provide the 
appropriate bee command level. At the "early" command level, the 
config deck must be made to be correct. At the "boot" command 
level, the mpes (other than the bootload tape mpc and all of the 
disk mpes) need to be loaded. 
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Within the command level , the config deck, (on disk, 
disk_eonf ig_deck) may have been modified. This is read in, via 
establ ish_conf ig_deck, for the next initialization pass. For 
cold boots, the generated config deck is written out instead. 

When the pass is over, the states saved at the beginning of 
the pass are restored, the system is masked, and we proceed to 
perform another pass. 

SERVICE PASS 

The sequence of events in a service pass differs from the 
normal pass in many ways. 

After initial ize_fauVts$fault_init_one runs, 
move_non_perm_wired_segs is called to move the segments loaded by 
collection to their proper places, thereby utilizing all of the 
boot load memory. 

[Collection assumes 51 2K of boot load memory, for two 
reasons. First, if BOS and the config deck are not present, 
there is no easy way of finding out how much memory there is, so 
some assumption is needed. Second, the crash handler will have 
to run in some amount of memory whose contents are saved on disk. 
51 2K is a reasonable amount of space to reserve for a disk 
partition. At current memory and disk prices it is hard to 
imagine anyone with a bootload controller with less that 51 2K, or 
a problem with the disk partition. 

When setting up the service environment, though, it is 
necessary to move the segments that have been allocated in the 
51 2K limit. It is desirable to have sst_seg and core_map at the 
high end of the bootload memory controller. (On the one hand, 
the controller they reside in cannot be deconf igured. On the 
other hand, only the low 256K of memory can be used for I/O 
buffers on systems with IOM's not in paged mode. While we could 
just start them at the 256K point, that might produce 
fragmentation problems. So the top of the controller is best.) 
If the controller really has 512K of memory, collection 1 paged 
segments will be there. move_non_perm_wired_segs takes the 
segments that the collection zero loader allocated high (paged 
segments and in it segments that are not firmware segments) and 
moves them to the highest contiguously addressable memory, 
hopefully leaving the top of the low controller for the sst_seg 
and cor e_ map. 3 

tc_init sets the number of aptes and itt entries on the 
basis of" the ted card, A normal bee pass really needs no such 
entr ies. 

init_sst generates the sst snd core map appropriate for all 
of memory" at the top of the bootload memory. A normal pass 
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allocates these tables through normal off-the-slt allocation 
(because the top of the 512k. area is filled with temp segs) . 

Since the service pass does not come to bee command level, 
establ ish_temp_segs, f ind_f i le_part i t ion and 

load_mst$ ini t_ commands are not run. 

init_ toehold is not run since upon a crash we want to 
return to the boot load environment and not to a state in which we 
are booting. 

ini t_parti tions checks the "part" config cards. 

NoWj the routine we've all been waiting for runs. 
make_segs_ paged causes all pagable segments to be paged into the 
various hardcore partitions thereby no longer needing memory. We 
can then run col lect_f ree_core to regain the freed space. 

delete_segs$temp deletes the segments temporary to collec- 
tion 1. We can then load, link, and run collection 2 (performed 
by segment_ loader, pre_link_hc and beyond). 

EARL Y PASS 

The early initialization pass is a pass through collection 
1 whose job is to set up paging and obtain the config deck from 
its disk partition so that a normal initialization pass may be 
run which knows about the complete set of hardware. 

It starts with ini t_ear ly_conf ig constructing a config deck 
based on assumptions and information available in sys_boot_ inf o. 
This config deck describes the boot load CPU, the low 51 2K of 
memory, the bootload IOM, the bootload tape controller and the 
boot load console. Given this synthetic deck, we can proceed 
through scs_and_c lock... ini t, etc. t© setup the environment for 
paging. scs_and_clock_ initSear ly fills the bootload CPU port 
number into the config deck, which is how it differs from 
scs_and_clock_ ini tSnormal . 

scas_init and init_scu (called from scas_init) have special 
cases for early initialization that ignore any discrepancy 
between the 512K used for the bootload controller and any larger 
size indicated by the CPU port logic. 

During the early pass (or, actually during the first "boot" 
pass, if an early pass is never run), ini t_bce$ wired sets up 
references in bce_data to wired objects. This allows 
bce_console_ io and other friendlier routines to run. 

To locate the RPV subsystem, find_rpv_ subsystem looks in 
sys„boot_ info. If the data is there, it will try to boot the RPV 
subsystem firmware (if needed). If not, it queries the operator 
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for the data. If, later in ini t ial izat ion,, the data should prove 
suspect (e.g. RPV label does not describe the RPV)j control 
returns here to re- query the operator. The operator is first 
asked for a command line specifying the RPV subsystem model and 
base channel j and the RPV drive model and device number. The 
operator may request that the system, generate a query in detail 
for each item. Cold boot is also requested in the 
f ind_rpv_ subsystem dialog. The simple command processor , 
bce_command_ processor _, is used to parse the "cold" and "rpv" 
request lines described above. 

The RPV data is filled into the config deck, and 
initialization continues with init_pvt and friends, 
ini t_root_ vols is called through its early entrypoint so as to 
allow for an error return. Errors occur ing during the ini ting of 
the rpv will cause a re- query of the rpv data by returning to the 
call to get_io_segs. 

Firmware is booted in the RPV controller by 
boot_rpv_ subsystem, called from find_rpv_ subsystem, which finds 
the appropriate firmware image and calls hc_load_mpc. A database 
of device models and firmware types and other configuration 
rules, conf ig_data_ . cds, is used to validate operator input and, 
for example, translate the subsystem model into a firmware 
segment name. 

ini t_roots_ vols checks for the presence of and creates 
certain key partitions on the rpv. The "conf" partition, if not 
present, is created by trimming 4 pages off of the hardcore 
partition. The "bee" (bee crash handler, temporary area and MST 
storage) and "file" (boot load file system) partitions are 
created, if any is not found, by a call to create_rpv_part i t ion. 
This program shuffles the disk pages to find enough contiguous 
space at the end of the disk for the partitions. 

After running establ i sh_temp_segs and f ind_f i le_partition, 
the rest of the MST is read. This step is performed during the 
"early" pass or whatever is the first boot pass, 
t ape_ readers ini t sets up tape reading. load_mst reads in collec- 
tion 1.2 (config deck sources and exec_ corns) into bee file system 
objects, collection 1.5 (bee paged programs and firmware images) 
into mst area pages leaving around traces for 
load_mstS ini t_ commands (which maps them into the bee address 
space) and saves collections 2 and 3 on disk for warm booting. 
tape_reader$f inal shuts down the tape. I oad_mst$ ini t_ commands 
then runs. 

The early or the first boot pass then initializes bce_data 
references to paged objects with ini t_bce$ paged. 

An early command level is now entered, using a subset of 
the real bee command level commands. This level is entered to 
allow editing of the config deck. 
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After leaving command levels init_clocks is called. This 
is the time when the operator sets the clock.. Up until this 
time 4 the times shown were random. If the operator realizes at 
this time that he must fix the config deck, or whatever , he has a 
chance to return to the early command level. When the clock is 
setj control proceeds. 

At this point j early initialization's work is done. The 
real config deck is read in (by establ ish_conf ig_deck) t and the 
system can rebuild the wired databases to their real sizes. 
Interrupts are masked, completion of pending console I/O is 
awaited, and the sit allocation pointers are restored to their 
pre-col lection- 1 values. Control then moves to the "boot" pass. 

CRASH PAS . S . 

The crash pass recreates a "boot" environment from which 
dumps can be taken and emergency„ shutdown can be invoked. It 
differs from the "boot" pass only in the verbosity (to avoid 
printing many messages at breakpoints) and in the command level 
that is reached. 

RE EARLY. PASS 

A re_ early pass is run to restore a safe environment 
following a failure to boot to the "boot" command level. It is 
identical to a "boot" pass except that it uses a saved config 
deck known to be good and reaches a "early" command level. 

BCE CRASH PASS 

The bce_ crash pass is run to restore a safe environment 
following a failure to boot the "service" pass. Thismay also be 
the result of a failure of a bee utility invoked at the "boot" 
command level. This pass is identical to the boot pass except 
that i t uses a saved conf i g deck known to be good and reaches the 
"bce_ crash" command level. 



SHUT PASS 

The shut pass is run when Multics shuts down., as opposed to 
crashing. It differs from the boot pass only in that 
load_disk_mpcs is not run, because it shouldn't be ncessary 
(Multics was using the mpes okay) and because it would interfere 
with possible auto exec_.com operation. 
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MSDULE DESCRIPTIONS 

Boot load Command Environment modules are not included in 
this section. 

announce chwm ■ p 1 1 

The name of this program means 
announce, Cor e_High_ Wat er_ Mark, It will announce the extent to 
which memory is filled during the various passes of collection 1 
when the "chwm" parameter appears on the "parm" card in the 
config deck. Near the beginning of each pass, this program 
announces the amount of memory used, based upon information in 
the sit. At the end of service ini t ial izat ionj it walks down the 
core map entries, looking for pages that are available to page 
control and those that are wired. The difference between the 
memory size and the total figure given here is the amount taken 
up by non-page control pages, the sst for example. As a side 
bonus, the before entrypoint announces the usage of 
int_unpaged_page_ tables; the after entrypoint announces the usage 
for unpaged. page_ tables. 

boot rov subsystem. pI1 

boot„rpv_ subsystem is the interface between 
find_rpv_ subsystem and hc_load_mpc, the hardcore firmware loading 
utility. All that it really has to do is find the appropriate 
firmware segment in collection 1. config_data_ is used to map 
the controller model to a firmware segment name, of the usual 
CT&D) form ( f w. XXXnnn. Ymmm) . The segment and base channel are 
passed to hc_load_mpc, and the results (success or failure) are 
returned to f ind_rpv_ subsystem. 

boot tape tPiPU 

This is the program that performs reading of the MST by 
collections 1 and beyond. It uses the physical record buffer as 
an i/o area. io_manager is used to perform the i/o, with dew 
lists generated within this program. 

boot! pad i ,alm 

bootload_l is the first collection 1 program., called 
directly by collection 0, It fills in the stack headers of the 
prds and inzr_stk0 to initialize the PL/1 environment. It then 
calls initial izer. pi 1 which pushes the first stack frame. 
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collec t free core .oil 

At the end of collection 1 service ini t ial izat iortj this 
program is called to free the storage taken up by the previously 
wired initialization segments. It does this by marking all core 
map entries for pages still unpaged (judged from the address 
field of the sdws of all segments) as wired and marking all of 
the rest as free (available for paging). It special cases 
breakpointable segments to avoid freeing references to 
br eakpo i n t_ page . 

create rov part it ion .oil 

To save the effort of creating the new Boot load Multics 
partitions by requiring all sites to perform a rebuild_disk of 
their rpv, this program was created. It creates partitions on 
rpv (high end) by shuffling pages about so as to vacate the 
desired space. The pages to move are found from the vtoces. The 
vtoces are updated to show the new page location and the vol map 
is updated to show the new used pages. This program uses 
read_disk to read and write the pages. No part of the file 
system is active when this program runs. 

delete segs.pll 

delete_segs is called after the various collections to 
delete the segments specific only to that collection (temp segs) . 
It is also called at the end of collection 3 to delete segments 
belonging to all of initialization (init segs). It scans the ast 
list for the appropriate segments, uses pcStruncate to free their 
pages ( in the hardcore partition) or pcScleanup to free the core 
frames for abs-segs and then threads the astes into the free 
list. This program is careful not to truncate a br eakpo int_ page 
threaded onto a segment. 



disk n 



disk_ reader is used by the 
tion 2) j segment. loader , and 
I oad_ system, to read the mst area 



collection 1 loader (of collec- 
by the collection 2 loader, 
of disk. It operates by paging 



disk through disk_mst_seg. The init 
disk_mst_seg unto the first 256 pages of the 
As requests come in to read various words., 
this segment. When a request comes in that 
is left in this segment s the remainder 
caller's buffer, and disk_mst_seg re- mapped 
pages. This continues as needed. 



entrypoint sets up 
mst area to be read, 
they are paged from 
is longer than what 
is placed into the 
onto the next 256 
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establish conf i a de ck. o 11 

The config deck is stored in the "conf" partition on the 
RPV in between boot loads. It runs in one of two ways, depending 
on whether it is setting up for service or bee use. For bee use., 
a abs-seg is created which describes the disk version. 
config_deck still describes the memory version. If it is 
necessary to read in the disk version abs_seg is copied to 
conf ig_ deck. Likewise, if some program ( conf ig_deck_edi t_ in 
particular) wants to update the disk version, abs_seg is again 
used, receiving the contents of conf ig_ deck. During service, 
conf ig_ deck is itself both wired an an abs-seg on the disk 
partition. This is done by creating an aste whose ptws describe 
memory. We make the core map entries for the pages occupied by 
conf ig_ deck describe this aste and the disk records of the conf 
partition- These erne's are threaded into page controls list 
(equivalent of freecore) providing a valid wired segment, at the 
address of conf ig_ deck. 

fill vol extents .oil 

This is the ring 1 program that obtains, through the 
infamous "init_vol loop", the desired parameters of a disk to 
initialize. It is called in initialization by init_empty_root 
when performing a cold boot to determine the desired partitions 
and general layout desired for the rpv, 

find pdv subsystem. oil 

f ind_rpv_ subsystem initializes configuration and firmware 
for the RPV disk subsystem. When available, it uses information 
in sys_boot_ inf o. When that information is not present, the 
operator is queried. The basic query is for a request line of 
the form: 

r^>v Ice MPC_ model RPV_model RPV_ device 
or 

cold Ice MPC_ model RPV_ model RPV_ device 

as described in the MOH. 

If the operator makes a mistake, or types help, the 
operator is offered the opportunity to enter into an extended, 
item by item dialog to supply the data. 

The information is checked for consistency against 
conf ig_data_, a eds program that describes all supported devices, 
models, etc. The mpc is tested through 
hc_ I oad_mpc$test_ control ler, to see if firmware is running in it. 
If the response is power off, then boot_rpv_ subsystem is called 
to load firmware, Then ini t_ear ly_conf igSdisk is called to fill 
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this data into the con-fig deck. If a later stage of 

initialization discovers an error that might be the result of an 

incorrect specification at this stage, control is returned here 
to give the operator another chance. 

The operator is also allowed to enter "skip_load" or 
"skip" j as a request before entering the rpv data. This forces a 
skip of the firmware loading, regardless of the apparent state of 
the mpc. 

aet i o seas . d 1 1 

A scan through the config deck determines the sizes of the 
various hardcore i/o databases which this program allocates. 
This program also fills in some of the headers of these databases 
as a courtesy for later initialization programs. The key 
determiners of the sizes of the tables allocated are the number 
of subsystems, the number of logical channels to devices, the 
number of drives, the number of ioms, etc. get_main is used to 
allocate the areas, using entries in the sit to find the memory. 
Areas allocated are: the pvt, the stock_segs, the disk_seg, 
ioi_data, iom_data and io_conf ig_data. 

get maJn.pn 

get_main is used to create a segment that is to reside in 
main memory. It runs in one of two ways, depending on whether 
allocation off the sit ( sit. free_ cor e_ start) is allowed. When 
this is not allowed (later in initialization), 
make_sdw$ unthreaded is used to generate the segment/ aste. 
pc_absSwire_abs_cont ig forces this segment to be in memory. 
Earlier in initialization (before page control is active), the 
segment is allocated from the free core values in the sit. These 
values determine the placement in memory of the to be created 
segment. get_main allocates a page table for this segment in 
either int_ unpaged. page_ tables or unpaged. page_ tables (depending 
on whether the segment will eventually be made paged). The ptws 
are filled in and an sdw made. The given_ address entrypoint of 
get_main can be used to utilize its unpaged segment page table 
generation capabilities (as in init_sst). 

he load mpc.pll 

hc_load_mpc embodies the protocol for loading all MpC's. 
It is an io_ manager client. Since the firmware must be in the 
low 256K, a workspace is allocated in free_area_1 and the 
firmware image is copied out of the firmware segment and into 
this buffer for the actual I/O. The urc entrypoint is used to 
load urc mpes. This entry accepts an array of firmware images to 
load. It scans the list to determine to which channels each 
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overlay applies. The extra entrypoint test_ control ler, used by 
find_rpv_ subsystem and load_disk_mpcs, tests a controller by 
executing a request status operation. The results of this are 
used to see if the mpc seems to be running (has firmware in it). 

init aste pools.pll 

This program is called exclusively from init_sst and really 
does most of its work.. It builds the four aste pools with empty 
astes appropriately threaded. Each aste is filled in with ptws 
indicating null pages . 

init c locks. pi 1 

This program performs the setting of the system clock. It 

starts by providing the time and asking if it is correct. If it 

is, fine. If the operator says it's not., the operator is 
prompted for a time in the form: 

yyyy mm dd hh mm (ss> 

The time is repeated back in English in the form "Monday, 
November 15 1982". If the boot load memory is a SCU, the operator 
is invited to type "yes" to set this time (when the time is met), 
or "no" to enter another time. The time is set in all the 
configured memories, to support future jumping clock error 
recovery. On 6000 SC's, the program translates times to SC 
switch settings. The program gives the operator time to set the 
clock by waiting for an input line. At any time, the operator 
may enter "abort", realising that something is wrong. 
init_clocks then returns. real_ initial izer will re-enter the 
early command level in this case. 

init early config.pll 

ini t_ ear I y_conf ig fabricates a conf ig deck based on the 
information available after collection zero has completed. The 
boot load CPU, IOM, console, and tape controller are described. 
The port number of the boot load CPU is not filled in here, since 
it is not easily determined. Instead, scs_and_clock_ ini t$ear ly 
fills it in. Appropriate parm, sst, and ted cards are 
constructed, and placeholders are filled in for the RPV 
subsystem, so that iom_data_ init will reserve enough channel 
slots. init_early_conf igSdisk is used to fill in the real values 
for the RPV subsystem once they are known. 
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in it emoxv root.Dll 

f i I l_vol_extents_, the subroutine used by the user ring 
init_vol command, has been adapted to provide the main function 
of this program. It provides a request loop in which the 
operator can specify the number of vtoces, partition layout, etc. 
The operator is provided with a default layout, including the 
usual set of partitions and the default (2.0) average segment 
length. If it is changed, the operator is required to define at 
least the hardcore and bee required partitions and (for the 
moment) the bos partition. 

in it he part.pll 

init_hc_part builds the appropriate entries so that paging 
and allocation may be done against the hardcore partition. It 
builds a pseudo vol map ( volmap_abs_seg) describing the hardcore 
partition (which is withdrawn from the beginning thereof) 
allowing withdrawing of pages from the partition. A record stock 
is also created of appropriate size for the partitions. 

in it part it ions .Pl1 

This program makes sure that the partitions the operator 
specified in the config deck are really there. It checks the 
labels of the config deck specified disks for the specified 
partitions. Disks that do have partitions so listed are listed 
as un- demountable in their pvt entries. 

inU pyt.pll 

The pvt contains relatively static data about each disk 
drive (as opposed to dynamic information such as whether i/o is 
in progress). init_pvt sets each entry to describe a disk. No 
i/o is done at this time so logical volume information, etc. can 
not be filled in. Each disk is presumed to be a storage system 
disk, until otherwise determined later. 

init root vols.pll 

ini t_root„vols finds the disks that will be used for 
hardcore partitions. It mostly finds the disks from root cards 
and finds the hardcore partitions from the labels. For the r-jpv J 
it will also call ini t_empty_ root, if a cold boot is desired, 
call cr eat e_rpv_ part i t ion, if various required partitions are 
missing (MR11 automatic upgrade), and set various pvt entries to 
describe the rpv. During the service pass, init_hc_part is 
called to establish paging (and allow withdrawing) against the 
hardcore partition. 
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in it scu. oil 

This routine is used within scas_init to in it a given scu. 
It compares the scu configuration information (from its switches) 
with the supplied size and requirements. When called for 
boot load Multics purposes, the size of the scu may be larger than 
that specified (generated) in the config deck without a warning 
message. It generates ptws so it can address the scu registers 
(see the description in the glossary for the seas). The execute 
interrupt mask assignment and mask/ port assignment on the 
memories is checked here. 



in it sst.pH 

init_sst starts by determining the size of the pools. 
Normally, this is found in the sst config card (although init_sst 
will generate one of 400 1 50 50 20 if one isn't found). For 
early and bootload Multics initialization, though, the pools 
sizes are determined from the current requirements given in 
figures in boot load_ inf o. The size of the core_map is determined 
from the amount of configured memory for normal operation and is 
set to describe 512K for early and bootload Multics operation. 
The area for the sst is obtained, either from the top of the 
bootload scu for normal operation or from the sit allocation 
method for early and bootload Multics operation. The headers of 
the sst and core map &re filled in. init_aste_pools actually 
threads the astes generated. The pages of memory not used in low 
order (or bootload (512k)) memory are added to the core_.map as 
free. For normal operation the other scu's pages are also added 
to the free list. col lect_free_ core will eventually add the 
various pages of initialization segments that are later deleted. 

in it vol header .pll 

ini t_empty_root uses this program to initialize the rpv. 
This routine writes out the desired label (which describes the 
partitions filled in by f i I l_vol_extents_) , generates an empty 
vol map and writes it out, and generates empty vtoces and writes 
them out. 

initial error handler.pll 

This any_other handler replaces the fault_ vector "unexpect- 
ed fault" assignments. It implements def ault_restart and 
quiet_restart semantics for conditions signalled with info, and 
crashes the system for all other circumstances. 
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initial ize faults, Pll 

initial ize_faults has two separate entries, one for setting 
things up for collection 1, and one for collections 2 and beyond. 
This description is for collection 1 
C initial ize_f aultsSf ault_ init_one) . initial ize_f aults_data 
describes which faults have their fault vectors set to 
f im$pr imary_f ault_entry ( scu data to pdsSf im_data) , 
f im$signal_entry (scu data to pds$signal_data) , 
f im$onc_ star t„shut_ entry (scu data to pds$f im_data) or 
wired_f im$unexp_ fault (scu data to prpdsSsys_trouble_data) (all 
others). Special cases are: lockup and timer runout faults are 
set to an entry that will effectively ignore them. Derails g© to 
f im$drl_entry to handle breakpoints and special drl traps. 
Execute faults are set to wired_f im$xec_f ault (scu data to 
prds$sys_ trouble. data) . . Page faults are set to pagef aultSfault 
(scu data to pdsipage_fault.dat a) . And connect faults are set to 
prds$f ast_connect_code (scu data to pr ds$ f im_ data) . Write access 
is forced to certain key programs to set values within them. 
Access is reset afterwards. These are pointers which must be 
known by certain programs when there will be no mechanism for the 
programs themselves to find them. An example is the pointers 
within wired_fim specifying where scu data is to be stored. The 
last thing done is to set the signal, and sct_ptr in the 
i nzr_ st kO stack header so that signalling can occur in collection 
1 . 

initialize faults data.cds 

This cds segment describes which faults go to where so that 
initial ize_fau Its can so set them. For collection 1, the major 
faults set are: command and trouble to f im$pr imary_fault_ entry 
(scu data in pds$f im_data) , access violation store, mme, fault 
tag 1, 2 and 3, derail , illegal procedure, overflow, divide, 
directed faults 0, 2 and 3, mme2, mme3, mme4 to f imSsignal_entry 
(scu data to pds$ signal. data) , shutdown, op not complete and 
startup to f im$onc_start_shut_entry (scu data to pds$f im_data) 
and the rest to wired_f im$unexp_f aul t (scu data to 
prds$sys_trouble_data) . 

initial izer .oil 

initializer consists of only calls to real_ ini tial izer, 
delete_segs$delete_segs_ ini t, and init_proc. real_ initial izer is 
the main driver for initialization. It is an in it seg. 
initializer exists as a separate program from real_ ini tial izer 
because, after the call to delete init segs, there must still be 
a program around that can call init_proc. This is the one. 
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iom data init.pll 



The 
used by 
mai 1 boxes 
val i dated 
descr i bed 



function of this program is to set up the data bases 
io_ manager. These include iom_data and the actual 
used in communicating with the iom. The iom cards are 
here. The overhead channel mailboxes are set for the 
channels. 



load disk mpcs.oll 



During the 
loaded into them 
scans the 
one (with 
apparently 
prints the 
load. bee, 



1 pass j all disk mpes must 
is done by load_disk_mpcs. 
searching for disk mpes. 



have firmware 

This program 

It tests each 



"boot" 
This 
conf i g deckj 

hc_ load_mpc$test_control ler) to determine a list of 
non - loaded disk mpes. If this list is not empty, it 
list and asks the operator for a sub- set of these to 
fwload is used to perform the actual loading. 



load mst.pll 

load_mst reads in the MST. It contains a routine which 
understands the format of a MST. This routine is supplied with 
various entry variables to do the right thing with the objects 
read from the various collections. For collection 1 . 2, the 
objects are placed into the bee file system through bootload_f s_. 
For collection 1.5, the segments have linkages combined, etc. 
just as in segment loader. The objects are placed on disk., in 
locations recorded in a table. These are paged bee programs. 
Collections 2 and 3 are simply read in as is, scrolling down the 
mst area of the "bee" partition using the abs-seg disk_mst_seg. 
The init_ commands entrypoint uses the table built while reading 
collection 1.5. The appropriate bee segments are mapped onto 
disk using the locations therein. 



make sdWiPlI 

make_sdw is the master sdw/aste creation program for 
collection 1 and beyond. It contains many special cases to 
handle the myriad types of segments used and generated in 
initialization. It's first job is to determine the size of the 
desired segment. The size used is the maximum of the site's 
current length, maximum length and the size given on a tbls card 

var iabl e_ tables) . Also, an extra 
when needed. Given this size, an 
and threaded into the appropriate 
segs, or normal segs. Wired segs 
listed as hardcore segments. The 
page table words are initialized to null addresses, If the 
segment is wired and is breakpointable, the last ptw is instead 
set to point to br eakpo i nt_ page . For abs-segs, this is the endj 



C if the segment's name is in 
page is added for breakpoints 
appropriate size aste is found 
list, either init segs, temp 
aren't threaded; they are just 
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abs segs and other "funny" segs must build their own page tables 
and a real sdw to describe them. For a normal segment , however, 
the page table entries are filled as follows". an appropriate 
hardcore partition to hold the pages is chosen. abs_seg's sdw is 
set to indicate this null address page table. The various pages 
are touched, causing page control to be invoked to withdraw an 
appropriate page against the hardcore partition whose drive index 
is in the aste. (abs_seg's sdw is then freed.) make_segs_ paged 
and segment. loader, the main clients of make_sdw, will then copy 
the desired data (either from wired memory or from the tape) into 
these new (pagable) pages. 

make seas paged. pi 1 

make_segs_ paged, that most famous of initialization pro- 
grams, actually, in a way, has most of its work performed by 
make_sdw. make_ segs_ paged examines all of the initialization 
segments, looking for those it can page (i.e., not wired, not 
already made paged, non-abs-segs, etc.). It walks down this list 
of segments from the top of memory down, using make_sdw to 
generate an aste, an sdw, and a page table full of disk pages for 
it. The sdw is put into dseg, and the contents of the wired 
segment is copied into the paged version. The pages of memory 
are then added to page control's free pool The dseg is also 
copied with a new dbr generated to describe it. 

Breakpointable segments are special cased in two ways. 
First of all j when the pages of the old segment are freed, 
occurences of breakpoint_page are not. Also, when copying the 
segment, breakpoints set within it must be copied. All of 
breakpoint_page cannot be copied since it includes breakpoints in 
other segments. Thus, we must copy each breakpoint, one at a 
time by hand. 

move non perm wired seas. Pi 1 

This program takes the segments allocated high addresses by 
collection (paged segments and init segments that are not 
firmware segments) which were put at the top of the 51 2K early 
initialization memory, and moves them to the top of the 
contiguously addressable memory, leaving the top of the low 
controller for the sst„seg and core_map. 

This program depends on the knowledge that the loader 
assigns segment numbers in monotonical ly increasing order to 
permanent supervisor and init segs, and that the high segments 
are allocated from the top of memory down. Thus it can move the 
highest segment (in memory address) first, and so on, by stepping 
along the SLTE's. 
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The copying of the segment can be tricky, though , since not 
only must the contents be moved but the page table must be 
changed to reflect the new location. For this, we build abs_segO 
to point to the new location. The segment is copied into 
abs_segO. We now make the sdw for the segment equal to that for 
abs_segO. The segment is now moved, but we are using the page 
table for abs_segO for it, not the one belonging to it. So, we 
fix up the old page table to point to the new location, and swap 
back, the old sdw. This starts using the new ptws in the old 
p I ace . 

Segments that were breakpointable (had breakpoint_page in 
them) must be special cased not to move the breakpoint page. 

ocdcm ,pll 

Within initialization, the ini t_al l_consoles entrypoint of 
ocdcm_ is called. This entrypoint sets up oc_data to a nice safe 
(empty) state. The various console specific parms are found and 
saved. The main loop examines all prph ope cards. They are 
validated (and later listed if cist is specified). For each 
console, a console entry is filled describing it. The boot load 
console, when found, is specifically assigned as boot load con- 
sole. As a last feature, the number of cpus is found. This is 
because the longest lock time (meaningful for determining 
time-outs) is a function of the number of processors that can be 
waiting for an i/o. 

ocdcm_ also provides for bee a special function. It 
maintains wired_hardcore_data$abort_request, set to true whenever 
the operator hits the request key when this was not solicited (no 
read pending). This flag is used by bce_ check. abort to 
conditionally abort undesired bee operations. 

prds init,pU 

This program simply initializes certain header variables in 
the prds. This includes inserting the f ast_connect_code, the 
processor tag, etc. 

ore 1 ink he. oil 

The linker for collection 2, this program performs a 
function analogous to that performed by bootload_ I inker . It 
walks down the linkage sections of the segments in question, 
looking for links to snap. slt_manager is used to resolve 
references to segments. A definition search is imbeded within 
this program. 
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read disk-PlI 

read_disk is the routine used to read a page from or to 
write a page to disk. The init entry point sets up rdisk_seg as 
a one page paged abs segment for such purposes. Actual page 
reading and writing consists of using disk_ control to test the 
drive (unless the no_test entrypoints were used), and then page 
control to page the page. For reads, we construct a page table 
word describing the page of disk. Touching rdisk_seg then reads 
it in. For writing, we generate a null address page table entry. 
When we write to it, a page of memory is obtained. By forcing 
the core map entry to describe the desired page of disk, unwiring 
the page and performing a pcScleanup (force write), the page 
makes it to disk. 



read disk label. pi 1 

To read a disk label, we call read_disk_ label . It uses 
read_disk to preform the i/o, Several such reads will be 
performed. if necessary. The label is validated through a 
simple check of label . Mult ics, label . version and 
label . t ime_ registered. 

real init ial izer . Pi 1 . pmac 

real_ init ial izer is the main driver for initialization. It 
largely just calls other routines to set things up, in the proper 
order. 

There are many paths through real. initial izer as described 
above. All paths set an any_ other handler of 
ini t ial_error_handler to catch unclaimed signals, which eventual- 
ly causes a crash. 

The main path through real_ ini t ial izer calls collection..! 
(an internal subroutine) multiple times and then passes through 
to collections 2 and 3. Each call to col lection_l , in the normal 
case, "increments" sys_ inf oScol lect ion_1_phase, thus producing 
the main set of collection 1 passes. Various deviations from 
this exist. Aborting disk mpc loading resets the phase to 
re_ early and branches back to the "early" command level. A 
failure when finding the rpv during the "early" pass retries the 
"early" pass. The reinitialize command resets the phase to 
"early" and then simulates the bee "boot" function, thus making 
the next pass become a new "boot" pass. 

When Mult ics crashes or shuts down, the toehold restores 
the machine conditions of bee saved in the toehold. These return 
the system to save_handler_mc, which quickly returns through 
ini t_ toehold to real_ ini t ial izer. The routine collection_1 
senses this and returns to the main collection_1 calling loop. 
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real, initial izer keys off the memory. state (determines between 
crashing and shutting down) and old. memory. state (state of 
crashed memory - determines crashed collection 1 phase) in the 
toehold to determine the pass to run next. 



real_ initial izer 
pl1_macro is used to 
initialization. This 
meter initialization. 



includes 
ass i gn a 
number can 
Before each 



is made to the internal procedur 
contain "123"b3 M "PNNN"b6 J wher 
binary coded decimal (P is the 
stop number obtained from a li 
toehold is active). 



a stop- on- switches facility, 
unique number to each step in 
also be used in the future to 

step in initial ization, a call 
e check. stop. If the switches 
e PNNN is the error number in 
collection 1 phase, NNN is the 
sting), bee is called (if the 



seas i n i t . d 1 1 

scas_init inits the seas (system controller addressing 
segment), "it is the keeper of things cpu and scu. The config 
deck is searched for cpu and mem cards which are validated and 
the boxes' switches validated against the cards. The scsScow 
(connect operand words) are filled in here with values so that we 
may send connects to the various processors. init_scu is called 
to set masks and such for the various scus. The port enables are 
set for the ioms. The cpu system controller masks are checked. 
Finally, if the cpus and ioms do not overlap in port numbers, the 
cyclic priority switches are set on the scus. 



scs and_clock ipit.pl 1 

This program initializes most of the data in the scs. In 
previous systems, the scs was mostly filled in its eds source. 
To support multiple initializations, though, the segment must be 
reset for each pass. This program also 
sys. infoS clock, to point to the 
Sear I y entrypoint, it fills in 
number i n the conf i g deck. 



has the task of sett ing 
bootload SCU. Finally, at its 
the bootload SCU memory port 
since it used that data in scs 



initialization. Initializing the scs consists 
about cpus and scus. 



of initiating data 



segment loader.pll 



segment. I oader 
It uses disk_ reader 
various records from 
records (denoting a 



and beyond, 
of disk. The 
marks, header 
the segments. 



is used to load collections 2. 
to read records from the MST 
the MST are either collection 
segment) or the data forming 
Given information in the segment header, an appropriately sized 
area in wi_ linkages, ws_ linkages, ai_ linkages or as_ linkages is 
generated. slt.managerSbui Id.entry chooses the next segment 
number (either supervisor of initialization) for the segment and 
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creates the sit entry. make_sdw creates an sdw an the page table 
and allocates disk space in the hardcore partition for the 
segment. With read/ write access forced for this new (pagable) 
segment j the segment is read from disk. Access is then set as 
desired in the header record. We loop in this manner until we 
encounter a collection mark when we stop. 



sit manager. pll 

This is a relatively simple program, 
s I t_ manager$ bui I d_ entry looks at the header read from an MST and 
builds a sit entry. The header defines whether this is a 
supervisor or an initialization segment (which defines from which 
set of segment numbers (supervisory start at 0, initialization 
start at 400 octal) it is given), what names to add to the name 
table, and whether this segment has a pathname which needs to be 
added to the name table (so that in it_ branches can thread them 
into the hierarchy). While it is building the entry, it hashes 
the names in the same manner as boot I oad_s I t_ manager . 
s I t_ managers get_seg_ptr uses this hash list to search for the 
segment name requested. 

sys i nf o . cds 

sys_info is described under data bases. 

tape reader .Dll 

tape_reader uses boot_tape_io to read MST tape records. It 
is capable of reading several tape records and packing them into 
a user supplied buffer. It validates the tape records it reads 
for Mult ics-ness, performing the (old) reading re- written record 
error recovery mechanism. 

tc jnJt.PlI 

tc_init is run in two parts, the second called part_2 run 
in collection 2. Part one, just called tc_init, allocates an 
appropriately sized tc_data (see the description of 
tc_data_ header, above) given the supplied number of aptes and itt 
entries. The workclass entries are initialized to their 
defaults. Workclass is set up for the initializer as realtime, 
etc. Everyone else is put initially into workclass 1. The aptes 
and itts Qro threaded into empty lists. Initial scheduling 
parameters are obtained from the schd card. The length of the 
prds is set (either default or from tbls card). The stack_0_data 
segment (which keeps track of the ring stacks given to 
processes when they gain eligibility) is initialized. Apte 
entries for the initializer and idle (boot load cpu) are created. 
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Final \y> memory is allocated for the pds and dseg of the various 
idle processes (which won't actually be started until 
tc_ init$part_2) . 
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SECTION 4 
THE BQOTLOAD COMMAND ENVIRONMENT 



Bootload Multics must provide a certain number of 
facilities when the storage system is not available. Examples 
are system dumps to disk, disk saves and restores } interactive 
hardcore debug (patch and dump) , and automatic crash recovery. 

INITIALIZATION 

There are two ways that the command environment is entered. 
When an existing system is booted from power -up (cool boot)j the 
command environment is entered to allow conf ig deck maintenance 
and the like. When the service system crasheSj the command 
environment becomes the crash recovery environment that oversees 
dumping and automatic restart. A full cold boot is a special 
case of a cool boot. 

The heart of the boot load Multics command environment (bee) 
runs mostly wired. The paged segments are paged temp segmentSj 
managed by get„temp__ segment, and friends, for such purposes as 
qedx buffers and active function expansion. The bee file system 
is paged. Also* some bee command programs are pagedj through the 
grace of load_mst. These are mapped onto an area of the bee 
partition. bee does not use the storage system, nor the hardcore 
partition. 

Certain special programs are run so as to initialize bee. 
These are: init„bce to enable the basic facilities of switches 
and areas and such; f ind_f i le_partition to enable the boot load 
Multics file system; establ ish_temp_segs to provide paged temp 
segments; and 4 I o ad_ ms t$ ini t_ commands to allow references to 
paged bee programs. load_mst was described under the bootload 
Multics initialization pass in collection 1. 

ENVIRONMENT &MQL FACILITIES., 

The basic facilities of the command environment are: 
* 
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a free area. free_area_1 is initialized with def ine_area_ J 
and a pointer left in stacks header, user_free_area and 
stack.header . system_free_area, so that allocate statements 
with no "in" qualifiers work. get. system. free. area. () will 
return a pointer to this area. This area is used for global 
data needed between commands. Each command normally finds 
its own local area, normally on a paged temp segment. 

standard inputs output and error entries that hide the 
distinction between console and "exec.com" input. These are 
entry variables in the cds program bce_data. cds. They are 
hardly ever called directly, as more sophisticated 
interfaces are defined atop them. The entry variables are 
bee. da ta$ get. I ine, bce_data$put_ chars and 

bee. data$ err or. put. chars. get_chars is not sensible in the 
console environment , for the console will not transmit a 
partial line. The module bce_console_ io is the usual target 
of the entry variables. It uses ocdcm_ J oc_trans_ input_ and 
oc_trans_output_ . bce_data also contains the pointers 
get_l ine_data_ptr, put. chars. data.ptr and 

error_put_chars_data_ptr which point to control information 
needed by the target of the entry variable. The pair of 
values of an entry variable followed by the data pointer is 
what constitutes a bee switch. A pointer to this switch is 
passed around much as an iocb pointer is passed around in 
Multics. Both ioa_ and formline. understand these bee 
switches so that normal calls may be made. 

bee. query and bce_query$yes_no. Each takes a response 
argument, ioa_ control string, and arguments, and asks the 
question on the console. An active function interface is 
provided. 

bce_ error is the local surrogate for com. err., used by 
various non command level programs. It does not signal any 
conditions in its current implementation. com.err. and 
act i ve.f nc.err. simply call bce_error appropriately when in 

bee, 

a command processor. The standard command. processor, is 
used to provide a ssu_-like subsystem facility. The various 
command programs are called with a pointer to 
bce_ subsystem. info_ , of which the arg_list_ptr is the impor- 
tant information, 

a request line processor. Any program that wants to parse 
lines using standard syntax (without quotes, parentheses, or 
active functions, for now) calls bee. command. processor, with 
the command line, a procedure that will find the command, 
and a return code. f ind.rpv. subsystem, for example, calls 
it with an internal procedure that checks that the command 
is either "rpv", "cold", "help", or "?", and returns the 
appropriate internal procedure to process the command, 
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These procedures use the usual cu_ entrypoints to access 
their arguments. 

* The paged temp segments bootload_temp_1 . . bootload_temp_N. 
These are each of 128/N pages long, and mapped as abs-seg's 
onto a part of the bee partition. N is established by the 
number of such segments I i sted i n the MST header C and 
computed by establ ish_temp_segs) . These segments are 
managed by get_temp_ segments, and friends. 

* A primitive file system. bootload_fs_ manages a simple file 
system mapped onto the "file" partition on the rpv. This 
file system can hold config files or ex ec_ corns. It is 
writable from within Multics service. The objects in the 
file system have a max length of 128/N pages, matching that 
of the temp segments, and have a single name. 

* The standard active function set. 

* Disk i/o facilities. Several exist. Some utilities call 
(read write)_disk. If they do not need the disk, test that 
this routine performs (as when accessing the (already) 
trusted rpv) j they call the no_test versions of these 
entrypoints. Another mechanism is to build a paged segment 
onto the desired disk, area, normally via map_onto_disk. 
This mechanism trusts the built in mechanisms of page 
control (and traffic control disk polling) to ensure that 
the i/o is noticed. A final mechanism is to call 
dctl$bootload_(read write), which allows the queue ing of 
multiple i/os to different disks. This is used for high 
volume operations, such as pack copying. 

RESTRICTIONS 

Various Multics faculties are not present within bee. Some 
are listed below. 

* No operations upon the file system hierarchy are allowed 
(except for indirect references by bce_probe to segments in 
the Multics image). 

* Normal segment truncation/ deletion/ creation is not allowed. 
The ptws must be manually freed. 

* Segments may not be grown (no withdrawing of pages is 
allowed). They must be explicitly mapped onto the desired 
free area of disk or memory. 

* No iox_ operations are allowed. Pseudo- iocb" s do exist, 
though. 
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Only a finite (and small) number of paged/wired work areas 
can exist. They also have comparatively small lengths. 

Dynamic linking is not done. References to object names are 
done with s I t_ managers get_seg_ptr. 

Wakeups and waiting for wakeups can not be done. A program 
must loop waiting for status or use pxss facilities. 

Timers ( cput and alrm) may not be set, Programs must loop 
waiting for the time, 

There are no ips signals so no masking is involved. The 
real question is the masking of interrupts ( pmut$set_mask) . 

Any routine that itself , or through a subsidiary routine, 
calls bce_check_ abort (which includes any output operation), 
must be prepared to be aborted at these times. Thus, they 
must have a pending cleanup handler at these times, or 
simply have nothing that needs to be cleaned up. 



MODULE DESCRIPTIONS 



bee abs se^ 

This relatively uninteresting program maintains a list of 
abs-segs built during an initialization pass. This is done so 
that real. initial izer can free them, en masse, when it needs to 
reinitialize before another pass. 



bee alert.pl 1 



alert messages (mostly for bee ex ec_ corn's) are 
bce_ alert. It simply appends its arguments, 
a space) into one string which it prints through 

bce_data$console_alert_put_chars. This prints the message with 

audible alarm. 



Console 
produced by 
separated by 



bee alT Ldie^alm 

bce_alm_die wipes out the bee toehold and enters a "dis" 
state. 



bee appending simulat ion. pi 1 

All references to absolute and virtual addresses within the 
saved Multics image are performed by bce_ appending. simulat ion. 
It has multiple entrypoints for its functions. 
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The "in it" entrypoint must be called before all others. It 
initializes certain purely internal variables, for later effi- 
ciency. As an added bonus., it sets the initial dbr for the 
appending simulation based on whether it is desired to examine 
the crash image or bee itself. 

The entrypoint "new_dbr" sets a new dbr for the simulation. 
This entrypoint takes apart the dbr supplied. The main purpose 
of this entrypoint is to find this new address space's dseg, so 
it can evaluate virtual addresses. This fetching of the descrip- 
tion (aste/page table/sdw) of dseg can be done using the absolute 
fetching routines of bce_ append ing_ simulation and by manually 
disecting sdws and ptws, This entrypoint must also find the 
cor e_ map, if present, which is needed by the virtual entrypoints 
to find out-of -service pages. 

The "(get put) _( absolute virtual)" address entrypoints 
actually perform the fetching or patching of data. They take the 
input address and fetch or replace data in pieces, keeping each 
piece within a page. This is done because different pages 
desired may reside in totally different locations. 

"get_ absolute" and "put_ absolute" work in relatively simple 
ways. They examine the address to determine its location. Some 
low memory pages will be in the image on disk and fetched through 
the paged abs-segs multics_(low high)_mem. Other pages are in 
memory (above 512k). These are fetched through the abs-seg 
abs_segO which this program slides onto a 256k block as needed. 
References to absolute locations in examine- bee mode always use 
the abs_segO approach to fetch everything from memory. These 
entries keep a page_f aul t_error handler to catch disk errors, a 
store handler to handle memory addreses not enabled at the 
processor ports and an op_not_ complete handler to catch refernces 
to scu's who have our processor disabled. 

Before virtual addresses may be fetched/ patched, the 
"new_ segment" entrypoint must be called. The purpose of this 
entrypoint is to fetch the sdw/ aste/page table for the segment 
for later ease of reference. This is done by using the 
"get_ virtual" entrypoint, referencing dseg data given the previ- 
ously discovered description of dseg (in the "new_dbr" 
entrypoint). For efficiency in fetching the sdw (meaningful for 
the dump command which calls this entrypoint for every segment 
number valid in a process and ends up fetching null sdws), a dseg 
page is kept internal to this routine, 

Virtual addresses are manipulated by the "(get 
put) _ virtual" entrypoints. These entrypoints break apart the 
request into blocks that fit into pages. For each page of the 
segment that it needs, it examines its ptw (found in the segment 
description found and provided by the "new_ segment" entrypoint) 
to determine its location. Pages flagged as in memory are 
obtained by the absolute entrypoint. Pages on disk can be easily 
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manipulated by mapping rdisk_seg onto the page and paging it. If 
it is in neither catagories, something is either wrong or the 
page is out of service. For out of service pages (pages with i/o 
in progress upon them) , the "correct" page is found (the page at 
the source of the i/o) and this manipulated. If this is a put 
operation., it is necessary to replace this page in both locations 
(both memory and the disk page in use) to make sure that the 
effect is felt. AlsOj for any put operation the proper page 
table word must have its modified bit set so page control notices 
the modification. 

bee check abo rt ,p11 

bce_check_ abort contains the logic for possibly aborting 
bee functions upon operator request. When called, it checks 
wired_hardcore_data$abort_request J which is set by ocdcm_ whenev- 
er an unsolicited request is hit. If this bit is set, 
bce_check_ abort prompts the operator with "Abort?" to which the 
response determines the degree of abort. Both this query and the 
response i/o are performed through bce_ data$conso I e_[ whatever] to 
force them to appear on the console. A response of "no" simply 
returns. "yes" and "request'' signals sub_request_abort_j which 
is intercepted by the bce_exec_com_ and bce_.listen._j or by a bee 
subsystem. Entering "command" signals request, abort.., handled by 
bce_exec_com_ and bce_listen_ to abort a subsystem. Entering 
"all" performs a non-local goto to <sub-sys inf o> . abort. label , 
which returns to bce_.listen„ at top level. 

bce_check_ abort is called on the output side of 
bce_console_ io and other output oriented bee i/o modules. Thus, 
most operations will notice quickly the operator's intent to 
abort. However j any program that can enter an infinite 
computational loop (such as the exex_.com processor trying to 
follow an infinite Sgoto ... Slabel loop) must call 
bce_check_ abort within the loop to provide a way out. 

bee command processor . oil 

This routine is a scaled down version of 
command. processor... It does not support active functions or 
iteration sets. Written as such., it does not need the various 
work areas that command_processor_ needs and can run completely 
wired. It separates the command line into the usual tokens, 
forming an argument list of the various argument strings. It 
uses a routine supplied in its call to find an entry variable to 
perform the command found. It is used in various very early 
initialization programs like init_clocks and f ind_rpv_ subsystem 
(which obviously cannot page) as well as some boot load Multics 
programs that can deal with the simplicity and wish not to power 
up command_processor_ . 
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bee console io.pll 



bce_console_ io is the interface 
Its function is to perform 



( oc_trans_ input_ 
ocdcm_$pr i or i ty_ i o 
is the routine 
bce_data$get_ I i ne 
normally found 
bce_ dataS err or _put_ chars. 



to the console dim ocdcm_ . 

translation appropriate to the console 

and oc_trans_output_) and to call 

to perform the i/o. bce_console_ io$get_l ine 

normally found in the entry variable 

and bce_console_ io$put_ chars is the routine 

in bce_data$put_ chars and 



pee continue,. q\\ 



bce_continue restarts the interrupted image. It flushes 
memory and uses pmut$ spec ial_bce_ return to invoke the toehold. 
As it passes, it resets all rtb flags in the flagbox except 
ssenb. This is so that the next return to bee does not show the 
current rtb flags. 

Also present in this module is the bos command, which 
flushes memory and uses pmut$special_bce_return to invoke the BOS 
toehold. 



bee data . eds 

This eds segment contains data pertinent to th 
environment activities of bee. It holds the entry 
pointers used to perform i/o on the pseudo 
bce_data$get_ I inej bce_data$put_. chars, bce_data$ err or. 
and bce_data$exec_com„get_l ine. It keeps track of th 
exec_.com level j through bce_data$command_abs_data_ptr 
the exec_com_get_ I ine switch). It also holds the 
subsystem info for the command level in bce_data$subsys_ 



e command 

and data 

switches 

put_ chars 

e current 

(part of 

top level 

inf o_ptr. 



bee die-PU 

This module just checks to see 
is actually performed by bce_alm_die. 



if it is okay to die, which 



bee display instruction ,d1.1 

One of the bce_ probe 
bce_d isp I ay_ instruct ion_ displays one 
instruction. It uses op_mnemonic_ for 
result is to 
words dumped. 



support utilities, 
(possibly multi-word) 
its information. The 
print an instruction and to return the number of 
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bee display scu .pll 

bce_display_scu_ is another bce_ probe utility. It displays 
the scu data found in machine conditions supplied to it. 
bce_di sp I ay_ instruct ion_ is used to interpret the instruction 
words from the data. 

bee dump. Pi 1 

The disk dumping facility of bee is found in bce_dump. It 
is actually a rather simple program but with a few tricky special 
decisions made within it. After parsing the command line 
arguments, it figures out the process and segment options to use. 
These options are merged together in a hierarchical fashionj that 
is, options applying to all processes apply to eligible; all that 
apply to elgible apply to running, etc. The dump header is 
filled in with machine state information from the toehold. The 
dump header on disk is flagged as invalid. An abs-seg (dump_seg, 
created by establ ish_temp_segs) is built to run down the dump 
partition during segment placing. Given this out of the way., 
dumping can start. Each apte is read from the saved image 
(through bce_appending_simulat ion) . For eachj the segment 
options applying to each are determined. Given the segment 
limits in the dbr for this process, each segment is examined to 
see if it meets the segment options. Most of the options are 
self-explanatory. When it comes to dumping non-hardcore seg- 
ments, though, it is desired to dump any hierarchy segment only 
once. This is done by keeping a pseudo bit- map of the sst, where 
each bit says that a segment has been dumped. (Since the 
smallest possible aste in the sst is 16 words, there can be at 
most 256K/16 astes. Given an address within the sst from a 
segments' sdw, we assume that any aste that crosses the mod 16 
boundary near this address describes the same segment as this and 
need not be dumped again.) If a segment is to be dumped, we read 
pages from its end, looking for the first non-null page. All 
pages from the beginning of the segment up to and including this 
page are appended to the dump. (The dump_seg abs-seg is adjusted 
to indicate these pages.) When all is dumped., we update the 
header and write it out. 

bee error pU 

A simplified form of com_ err_, bce_ error simply fetches the 
text of an error message from err or_table_ and constructs an 
error message which is printed through bce_data$error_put_ chars. 
The com_ err entrypoint is used to format a com_err_ style 
message, used by com_ err„ when called during initialization. 
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bee esd . p 11 

An emergency shutdown of Multics is 
It uses bce_ continue to invoke the toehold 
However j before doing this^ it patches the 
the toehold to force the image 
emergency_ shutdown I 0, to perform an esd. 



initiated by bce.esd. 
to restart the image, 
machine conditions in 
to transfer to 



bee exec com ,d!1 

bee. exec. com. , along with bce_exec_com_ input, form the bee 
equivalent of version 1 exec. corn's. bce_exec.com. is a merging 
of functions found in exec_.com with those found in 
abs_ io_$ attach. It finds the ec and builds an appropriate 
ec_ info and abs.data structure to describe it. The ec attachment 
is made (bce_data$exec_com_get_l ine) is made to refer to this ec 
invocation, after saving the previous level. Commands are read 
from the ee through bce_exec_com_ input and executed through 
command.processor.Ssubsys.execute.l ine. Once bce_exec_com_ inf o 
returns a code for end of file, the ec attachment is reverted. 

bpe exec com input. p 11 

bce_exec.com. input performs the parsing of exec_coms. It 
is a pseudo i/o module, in the style of bce_console_ io$get_l ine. 
It is called in two possible cases. The first is to fetch a 
command line for execution by bce_exec_com_ . In this ease, the 
switch is bce_data$exec_com_get_l ine. When an Sattach appears in 
an ec, bce_ ex ec_com_ input will have attached itself (by making 
bce_ data$ get_ I ine point to itself) and then calls to 
bce_data$get_l ine will call bce_ ex ec_com_ input for a line where 
the switch ( bce_dats$get_l ine) will point to the abs_data for the 
ec that performed the Sattach. The basic code is stolen from 
abs_ io.vl.get.l ine_ . The major changes are to delete 
non- meaningful operations like Sec.dir. 

bee execute command .pll 

This routine is the caller for the various bee command 
programs. It is passed as an argument to, and is called, from 
command. processor _$subsys_ execute. I ine. It is given a pointer to 
an argument list generated by command. processor., as well as the 
request name. bee. execute. command. uses bce_ map. over. requests, 
to scan through bce.request.table. to find the entry to call. It 
understands the difference in calling between Multics routines 
(like active functions stolen from Multics) and bee routines. It 
also understands the flags indicating within which command levels 
a command is valid. 
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bee fwload.pll 



Firmware is loaded into various mpes by bce_fwload. Its 
objective is to find, for each mpc desired 4 the set of firmware 
images needed for it. hc_load_mpc does the actual loading. For 
a normal (disk, tape) mpc, this involves just finding the mpc 
card which shows the model. The model implies the firmware 
module needed Cconf ig_data_$ mpc_x_ names. fw_ tag) , The desired 
module is found through slt_manager. (Firmware images for disk, 
were part of collection 1 and are wired £ they needed to be in 
memory to be able to load the rpv controller); other images were 
part of paged collection 1.5.) For urc controllers, the main 
firmware can also be derived from the mpe's 
it is necessary to check, all prph cards 
accessible through that urc. For each, and 
channel it i s attached to, the appropriate 
found and put in the correct slot in the 
load. 



mpc card. However, 
to find peripherals 
depending on the urc 
f i r mwar e over I ay is 
list of firmware to 



bee get f. I aebox . p 1 1 

This module performs the bee (get set)_f lagbox 
commands/active functions. It is basically a version of the 
corresponding Multics routine, modified to make direct references 
to the flagbox instead of a gated access. 

bee get to command level. oil 

The routine to get from real. initial izer into command level 
is bce_get_to_ command. level . It builds a bce_ subsystem. info_ 
structure which it passes to bce_listen_. It examines the 
current state to determine if the initial command should be null 
(manual entry), the flagbox bee command (normal) or probe 
(breakpoint entry). Since it is the routine below 
real. initial izer on the stack, it is the routine to which control 
must return so that real_ initial izer can be returned to to 
perform boot and re. initial ize functions. Thus, boot and 
re_ initial ize are entrypoints within this program. re_ initial ize 
just returns, setting the col lection. 1_ phase to "early" so that 
real. initial izer will end up running another boot pass. This 
will cause boot load Multics to pick up any changes that have been 
made to the config_deck. boot scans the arguments which are 
inserted into the intk card. It then returns. 



bee i nst 



.J21L 



Another bce_ probe utility. This routine is used to deter- 
mine the length of an instruction, so that it may be correctly 
relocated. It differs from the real probe's version in that it 
does not attempt to deal with xec instructions. 
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bee list req uests .oil 

This program implements the I ist_requests < Ir) bootload 
Multics command. It does a simple minded walk down the bootload 
Multics request table, using bce.map.over.requests., with a 
printing routine to print the request names and the description 
within the table. It understands the dont_list flag, as well as 
understanding flags indicating at which levels a given command is 
val id. 

bee listen .pll 

bce_ listen is a simple loop that reads a command line from 
bce_data$get_l ine and executes it through command. processor, 
(using bee. execute^ command, to actually execute the request). It 
contains the sub_request_abort_ and request. abort, handlers to 
work with the operation of bce_ check. abort. 

pee map over requests .oil 

Programs that wish to walk down the bootload Multics 
request table ( bee. 1 ist. requests, and bee. execute. command.) call 
bee. map. over. requests, with a routine that is called on each 
entry in the table. As suchj the format of the table itself is 
known only to this routine. 

b_ce_ name .&o_- segnum .P\1 

This bce.probe utility maps segment numbers to names. It 
searches the sit and name. tables from the saved image. 
Entrypoints exists to convert a segment number to a hardcore 
segment name Cbce.segnum.to.name.) , a segment pointer to a 
virtual name (bee. segptr. to. name.) ., and a segment name to a 
segment number ( bee. name. t o_ segnum. ) . 

bee probe . d 1 1 . omac 

The main portion of bee's probe support , bce.probe contains 
the main drivers for most of probe's facilities. It contains the 
request line parser, address and value parsers and most of the 
functional routines. 

bce.probe starts by examining its arguments and its envi- 
ronment to determine its operating mode. It defaults to 
examining the breakpoint image if the flagbox indicates a break, 
to examining the crash image, when at bee. crash or crash command 
levels or to examining bee otherwise. Given its operating mode, 
it initializes the appending simulation package accordingly and 
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establishes a few initial constants. If in break mode, it 
determines the point of break, for operator information. 

bee proceeds to read request lines from the console. The 
first "string" in the line (or partial line left, if this is a 
multiple request line) found by internal routine get_ string 
becomes the request name. This is looked up in a table and 
dispatched through a "case" statement. 



REQUEST ROUTINES 



The before request finds the desired address. It is 
validated to ensure that it is virtual and that the segment named 
is breakpointable. Finding the breakpoint page for this segment, 
this request looks for an empty break slot. The original 
instruction is relocated there ( bce_relocate_ instruct ion_) and 
replaced by a transfer to the break block, The break block 
consists of a "drl -1" instruct ion; which causes the break, 
followed by the relocated instruct ion, followed by a transfer 
back to just after the original instruction in the code. This 
break block and the transfer to the block are patched into the 
segment such that failure at any time will not damage the 
segment. 



bee. 



The continue 
continue. 



request validates itself 



and 



cal Is 



dbr, 



The dbr request fetches its 
it calls internal routine new. 



arguments, 
dbr. 



Constructing a new 



The display request gets and validates its arguments. It 
loops, fetching (through bce_probe_f etch_) at most a page at a 
time to display (since we only allocate a one page buffer for the 
fetch). The internal routine "display" displays the data in the 



specified mode. Since data 
boundaries, any data "display" 
need data from the next page to 
front of the page buffer and a 



to be displayed may cross page 
cannot display (because it would 
fill out a line) is "scrolled" in 
new page worth's of data fetched. 



This continues until the last page is fetched. 

The let request finds the address and sets up for patching 
of same. It then loops, finding values from the request line, 
converting them to binary. These are appended unto a word based 
buffer. When all are fetched, they are patched into place. 

The I ist_ requests request simple prints a canned list of 
requests. 

The mc request gets its address and uses bce_ d i sp I ay_ scu_ . 

The name request uses bce_segnum_to_name_ . 
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The proc request fetches the desired apte from tc_data in 
the image. A new dbr value found therein is passed to internal 
rout i ne " new_dbr" . 

The quit request quits, 

The reset request performs the inverse of the before 
request. After validating its address (for virtualness, 
breakpointabi I ity, etc.), it undoes the effect of before, in 
reverse order to prevent damage to the segment. 

The segno request uses bce_name_to_segnum_ . 

The stack request validates its argument. Given the word 
offset therein, it decides whether to start from the specified 
stack, header or frame, The needed data is fetched and displayed 
in interpreted form. Each stack, pointer fetched is validated, 
not only to insure that it is a valid pointer, but to insure that 
stack frame loops do not cause bee probe loops. 

The status request uses the internal routine "status" to 
display breakpoints set. It simply validates its argument and 
decides between listing breakpoints for a segment versus listing 
breakpointed segments. 

INTERNAL ROUTINES 



check_no_more_args insures that no more arguments appear on 
the request line; that is, that we are looking at a semi -co I on or 
new- I ine. 

display displays data in a specified mode. It determines 
the bit sizes to display, alignments, etc. Its only trick is 
when processing the end. of a buffer full that doesn't fill a 
display line. This causes it to not finish its display. Its 
caller (the display request) then appends what was not displayed 
to the front of the next buffer full so that it may appear in the 
next group. 

function is used to parse functional references, such as 
"reg( ralr) " . function extracts the arguments to the function 
(whose identity was determined by its caller), builds an argument 
list from these strings, and calls the function. 

get_address contains the logic to parse a bee probe 
address. It fills in the structure, bce_probe_ data* address to 
define the current address. It special cases the dot (".") 
forms, checks for virtual forms (those with a " I " in them), 
notices absolute addresses (single octal number) and uses func- 
tion for the pseudo-var iable type of addresses (reg and disk). 
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Internal routines to get_ address, called by function, build the 
address structure for these types. 

get_string finds the next "string" in the request line. 
Its basic job is to pass whitespace and find string delimiters. 

get_ value finds a let request value. It looks for asci i 
strings (values starting with a quote character) , which it must 
parse separately (since quoted strings confuse the notion of 
string contained in get_string), finds virtual pointers (strings 
containing "I"), and finds the various numeric types. 

line_error i s used to print error messages. Besides 

printing the given message, optionally with or without the 

current request line arg or error code, it also aborts the 
current request line. 

new_dbr is the counterpart to the new_dbr entrypoint to the 
appending" package. It exists to set up references to a few 
popular segments (sit and name_table) whenever the dbr changes. 

pass_white passes whitespace. 

status displays breakpoint status. Since break blocks &re 

zeroed when not in use it is possible to find them easily. For 

any segment listed in the image's sit as being breakpointable, 

status fetches the last page (that which holds the breakpoints) 

and examines each break block. Any with a valid 
or iginal_ instr_ptr are displayed. 

bee probe data . cds. 

Information communicated between probe and its support 
routines is done so through bce_probe_data. This cds contains 
the current value of "." (current address), as well as pointers 
to bce_appending_seg_ info structures describing key segments in 
the image used by the support routines. 

bee probe fetch .pll 

This support utility to bce_probe fetches data, given a 
length and the current address (in bce_ probe_data$ address) . It 
simply uses bce_ append ing_ simulation for absolute and virtual 
address and read_disk for disk addresses. Register addresses 
must be specially handled by the caller. 

bee query .pU 

bce_ query is a simple-minded counterpart to command. query_ . 
It uses bce_data$put_ chars to print a question and 
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bce_data$get_l ine to read an answer, The main entrypoint accepts 
any answer and bce_query$ yes_.no accepts only yes or no which it 
returns as a bit. This routine is called with no prompt by some 
routines who find its return result (char (*)) to be better that 
the buffer and length and return length returned by 
bce_ dataS get_ line. 

bee ready. oil 

bce_ready prints the bee ready message: 

bee (BCE_CQMMAND_ LEVEL) TIME: 

It has a nnl entrypoint to print the message without new- I ine (as 
a prompt) j The normal entry prints the line (for ready message 
within exee_com) . 



bee relocate instruction 
This 



j__LL 



from the 

relocation 

attempting 



is another support routine for bce_probe. It differs 
standard Multics version in that it does not allow 
of "xec" instructions. (Service probe allows this by 
to examine the target of the xec, something bce_ probe 



does not attempt. ) 



bee request table .aim 



The boot 
table bui It 
pointer to th 
short name o 
request. The 
bce_ map_ over, r 
table. The I 
specify wheth 
command level 



load Multics request table is a normal ssu_ request 
with ssu_request_ macros. Each entry contains a 
e routine that performs a request t the name and 
f the request j and a short description of the 
actual threading of the entries is known only to 
equests_ J which performs the walking down of this 
ast three flags in each rq_data entry is used to 
er the command is valid at the three main bee 
types: earlyj boot and crash. 



bee sever ity.pll 

This is the bee counterpart 
command/ act i ve function. It does not 
doeSj however. Instead, it knows 
recognize a severity indicator. For 



to the Multics severity 
Work as the Multics routine 
the set of programs that 

the desired one, it calls 



the severity entrypoint thereof to find the severity. 



4-15 



AN70-01 



be e shutdown state .pll 

The current shutdown 
label . shutdown. state) 



read_disk to find this 



state of the storage system Crpv 
is found by this routine. It uses 
information. 



bee state. oil 

This command/ active function simply returns the name of the 
current bee state. 

boot I oad disk post ... p_l_1_ 

This routine is used in conjunction with the high volume 
disk facility of bee ( dctl$bootload_(read write)). Whenever a 
disk i/o queued through this means is posted for completion, it 
is done so through bootload_disk_post J called by either dctl or 
disk_ control . The result is posted in a structure described by 
bootToad_post_area. incl.pll. This area must be maintained by the 
cal ler . 

boot I oad fs ,Pll_ 

bootload_fs_ contains various routines to act upon the 
boot load Multics file system. The format of the boot I oad Multics 
file system is known only to this program. The file system is 
kept in a single abs-seg ( bootload_f i le.part i t ion) , mapped (and 
paged) off the bee partition on the rpv. A two page header at 
the start of the partition contains a directory of 174 entries 
(max that fits) listing the name, size and placement of the file 
within the segment. Also present is a free block map. Files are 
allocated as a contiguous series of blocks (64 word blocks) 
within the segment. The segment is automatically compacted by 
this routine when necessary, Entrypoints to this routine are: 
lookup (find the length of a file given its name) , list 
(allocates a list of file names and sizes within a user supplied 
area) , get (copies a file into a user supplied buffer) , get_ptr 
(returns a pointer and length to a given file ( hcs_$ initiate? )) , 
put (allocates area within the file system for a file and copies 
a user supplied buffer into it), put_ptr (allocates an area 
within the file system large enough for a given file and returns 
a pointer to it) (both put and put_ptr take an argument allowing 
for the deletion of a file with the same name as the one 
desired), delete (deletes a directory entry and frees the space 
used) , rename (renames a file (does not allow name duplication)), 
and init (clear out the boot load file system entirely). 
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boot l oad fs cmds .oil 

This program simply calls bootload_fs_ to perform the 
functions of the boot load Multics commands print, list, delete, 
rename, and initialize. This routine supports the star and equal 
conventions for most of its operations through match_star_name_ 
and get_equal_name_ . 

boot I oad aedx.pll 

bootload_qedx is a modified version of qedx. it differs in 
its use of file system operations ( bootload_f s_) and its use of 
temp segs. 

confia deck data . cds 

The config deck editor's source of config card descriptions 
is found in conf ig_deck_data_ . This cds provides labels for the 
fields, numbers and types of fields, etc. 

confia deck edit, .pi 1 

This is the program that edits config decks, It calls 
qedx_ to perform text editing, specifying the cal ler_does_ io 
option. With this option, qedx_ calls conf ig_deck_edi t_ to 
perform read and write operations on buffers. Any read/ write not 
to the config deck uses bootload_f s_. Reads/ writes to < config 
deck> (buffer 0) use the config deck conversion routines. This 
program makes use of conf ig_deck_ par se_, the routine that can 
convert from asci i Cpossibly labeled) form to and from binary 
form. The conversions are performed using a set of tables 
( conf ig_deck_data_) that describe the names of the fields, the 
required and optional number thereof, the data types of the 
fields, etc. Also allowed by the conversion routines are cards 
of types not recognizable starting with a dot (.) which are not 
validated. This is to allow for future expansion and site 
formatted cards. 

When a command line argument is supplied, the file 
specified is accessed ( bootload_f s_$get_ptr) and the object 
obtained is supplied to the internal routine wr it e_ conf ig_ deck 
which sets this new deck. 



estab i i sb-&amp_ s^gs_.jali 

Whenever bee needs (paged) temp segments, it calls 
get_ temp_ segment s_. get_temp_segments_ gets these segments from 
the pool of segments boot load_.temp_1 . . N. establ ish_temp_segs 
divides the temp seg pages allocated in the bee partition (128 
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pages) up into the N segments (N is determined from the number of 
such segments listed in the mst header). The paged segments are 
built as abs-seg's onto this area of the determined length. This 
size is saved in sys_ inf o$bce_max_seg_size. establ ish_temp_segs 
also creates the bee segments multics_(low high)_mem, used to 
access the saved image, dump_seg, used to access the dump 
partition and disk„conf ig_deck, used to access the rpv (real?) 
copy of the conf ig_deck (as opposed to our running copy in 
conf ig_deck) . 

find file part i t ion . pi 1 

f ind_f i le_partition maps the boot load Multics file system 
abs-seg ( boot load_f i le_part i t ion) onto the bee partition on the 
rpv in much the same manner as establ ish_ conf ig_ deck maps the 
config deck. It also calls bootload_f s_$ init to begin accessing 
the segment. If bootload_fs_ states that the file system is bad, 
f ind_f i le_partition will call bootload_f s_$ ini t again, this time 
to clear out the file system. 

init bee .Pll 

init_bce initializes the boot load Multics command environ- 
ment features required for future programs. It is called early 
in initialization. At its wired entrypoint, it sets up 
free_area_1 as an area, setting the inzr_stkO stack header to 
point to it so that allocates without an area work correctly and 
so that get_system_free_area_ also works. This routine also 
initially sets bce_data$get_Une, bce_data$put_ chars and 
bce_data$ err or_put_ chars to their appropriate entry values 
(bce_console_ io$get_l ine, bce_console_ io$put_chars and 
bce_console_ io$put_ chars, respectively) so that calls to 
bce_queryj bce_ error and especially ioa_, will work. At its 
paged entrypoint.. it. finishes, up references to paged objects, in 
particular, to the exec_com routines. 
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SECTI0N 5 
CRASH HANDLING 



Bootload Multics must be able to save the salient state of 
a crashing system and set up the command environment for dumping 
and other intervention. 

EARLY CRASHES 

Crashes in collection or the early initial izat ion pass of 
collection one should be very rare. Since the system uses a 
generated config deck, the set of possible operator inputs is 
small 4 and it is possible to do a much more thorough job of 
testing than can be done with BOS or service initialization. 
However, hardware problems will happen., and software bugs will 
sneak through. To cover these cases., collection includes a 
crash handler that can write a core image to tape, prompting the 
operator for the drive number. 

THE, Ifl.EH0.LD. 

The toehold, toehold, aim, is an impure, wired, privileged 
program that resides in a known location in absolute memory 
(24000o). It has entrypoints at the beginning that can be 
entered in one of two ways: with the execute switches processor 
function, or by being copied into the fault vector. The toehold, 
therefore, is entered in absolute mode. It must save the 51 2K 
memory image off to disk, and then load in the crash handler. 

The memory image includes the complete machine state. All 
absolute addresses, channel programs, port and channel numbers, 
and other configuration dependent information is stored into the 
toehold by a PL/ I program, ini t_ toehold. pi 1 . Thus the aim code 
does not have to know how to do any of these things, which 
simplifies it considerably. 

The toehold starts with the various entry sequencesj one 
for manual entry, one for Multics entry (which differs from 
manual entry in that the means of entry is to execute the entry 
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through a fault vector entry; it is necessary to update the 
machine conditions in this case to pass the instruction that 
caused the fault vector execution) and one for restarting the 
machine image. The crash entries save the entire machine state. 
This is done under the protection of the memory. state so that the 
machine state is not overwritten if the toehold is invoked again 
after being invoked after a crash. An internal routine performs 
i/o given a set of dew lists C built by ini t_ toehold) , After the 
memory is saved and the crash handler read inj the machine state 
of bee is restored. (It was saved by save_handler_mc. ) This 
causes a return into save_handler_mc J which quickly returns to 
ini t_toeholdj which quickly returns to real_ initial izer who 
quickly starts the appropriate crash initialization pass. 

On the restore side, the system is masked and the internal 
routine called to read back the saved image. The machine 
conditions are restored from the toehold (which is not 
saved/restored during the memory shuffle). 



MODULE DE SCRIPTIONS 



f imia .i ro . 

fim is listed in the crashing set of modules in as much as 
that it contains the bee breakpoint handler. A bee breakpoint 
consists of a "drl -1" instruction. fim's drl handler special 
cases these (in ring 0) , saves the machine state in 
breakpoint_page (after advancing the ic to pass the drl instruc- 
tion) and calls pmut$bce_and„return. It also performs the 
restart from a breakpoint. 



init toehold.pH 



This pll program constructs the channel 
and restore the 51 2K memory image, and fills i 
into the text of toehold. After saving the 
handler) on diskj it calls save_handler_mc to 
machine state of bee in the toehold. When bee 
crash., the bee restore operation will return 
save_handler_mc which will return to this point 
init„toehold notices this and quickly returns to 
who will perform the desired crash ini tial izatio 



programs to save 
t and other data 
bee image (crash 
save the current 
i s i nvoked upon a 
to the return in 

in ini t„ toehold. 

real_initiali zer 
n pass , 



savQ handler mcalm 



The save_handler„mc program, called from init_toehold right 
after it saves the crash handler to disk, saves in the toehold 



the machine conditions appropriate for bee. 



Besides register 
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contents and such, it saves the return address to the return in 
save_ hand I er_ mc . 
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SECTION 6 



COLLECTION 2 



of collection 2 is to make the storage system 
its way, it loads collection 3 into the 
places the appropriate entities from collec- 
tive hierarchy. The sub- tasks are to enable 
directory control. The real traffic control 
started. Since collection 2 runs in a paged environment 
not have the memory restrictions that collection 1 had. 
the reason why it is in a different collection from 



The main task 
accessible. Along 
storage system and 
tions 1 and 2 into 
segment control and 
is also 
i t does 
This is 



collection 1 



ORDER fiF EXECUTION 

The operations performed in collection 2 are described 



below. 

ini t ial ize_faults$f ault_ init_two is called 
fault vectors into the desired values for normal 
tion, now that the code for such has been loaded. 



to change the 
service opera- 



Initialization now runs performing several intermingled 
functions. All hardcore segments must be created now, before 
traffic control is fully initialized. This is so that the 
address space inherited by the new processes (idle in particular) 
encompasses all of hardcore. 

tty_buf, tty_area and tty_tables are generated through a 
call to fnp_init. They won't be needed at this time but must be 
allocated before tc_ ini t$part_2. 



Unique id (uid) generation is initialized 
getuid$ init. This is required before segments in 
C in particular, >sl1 and >pdd) can be created. 



by a call to 
the hierarchy 



i n i t_ vtoc_ man 
vtoc_buf f er_seg. We 
(and create) vtoces. 



allocates and 
are therefore eligible 



initial izes the 
to read and write 
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dbm_seg is allocated and initialized to an area by 
dbm_ man$ i n i t . init_ scavengers data allocates the sea venger_ data 
segment, used by the volume scavenger. The page control data 
base, dm_journal_seg_ J used to control synchronous page opera- 
tions (data management) j is initialized by ini t_dm_ journal., seg. 
dir_lock_seg, used to keep track of directory lockings and 
waitings thereupon, is initialized by dir_lock_ ini t. Again, 
these &ro created before tc_ ini t$part_2 is run. 

After this point, changes to the hardcore descriptor 
segment may not be reflected in idle process and hproc descriptor 
segments. This is because ini t_sys_var, which sets various 
system variables, uses the number of supervisor segments present 
(which is the expected total set thereof) to set the stack base 
segment number in various variables and in the dbr, 

We can now run tc_ ini t$part_2, which creates the idle 
processes and starts multiprogramming. At this time, only the 
boot load cpu will be running but the idle process will be enabled 
to run on it. 

With multiprogramming active, syserr_log_ in it can create 
the syserr hproc (after it makes the syserr partition accessi- 
ble). We then log a message to the effect that this was done. 

The activation of segment control, which began with the 
creation of the sst, continues now with the creation of the 
system trailer seg (str_seg) by ini t_str_seg. If the astk ( ast 
track) parm was specified, i n i t_ sst_ name_ seg initializes the 
sst_names_ segment with the names of paged hardcore segments. 

The entrybounds of hardcore gates are set via a call to 
in it_hardcore_ gates, which also stores linkage pointers into the 
gates for a reason described under the description of the 
program. 

We can finally make the volumes of the rlv accessible for 
storage system activity by a call to accept_rpv. This sets up 
the volume and vtoc maps and stocks for the drives, allowing 
vtoc_man and the page creat ion/ destruction functions to work 
against the paging region of the disks. 

The logical volume table ( Ivt) is initialized to describe 
the rlv by init„lvt, 

bad_dir_ and seg_f au I t_ handlers are now set up as we are 
about to access our first directory. ini t_root_dir makes the 
root directory known in the Initializer's process, creating it if 
this is a cold boot. The functions performed here are those that 
will allow future hierarchy segment references through segment 
control (kst creation, in particular). kst_ut i l$garbage_col lect 
is called just to make the kst neat. At this time, we can 
consider segment control to be active. We can call upon it to 
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create, delete or whatever. The presence of the root will allow 
these activities by virtue of the special casing performed by 
segment control when it discovers a segment with no parent (the 
root) . 

The hardcore entities which need to be placed into the 
hierarchy (deciduous segments) are done so by ini t_ branches, 
which also creates >s!1 and >pdd appropriately. These entities 
will be needed when we try to leave ring zero. Of course, other 
required segments are needed] these are the contents of collec- 
tion 3, 

init„stack_Q then runs to create the various stack_0's to 
be shared between eligible processes; now that it has a place to 
put them. 



delete_segs$temp can now rurij deleting collection 2 tempo- 
rary segments. This ends collection 2. 

M6DULE DESCRIPTIONS 

accept _ fs disk, P 11 

A disk, is accepted into the file system by accept.f s.disk. 
It validates the pvte for the disk. The label is read. (If this 
is a pre-MR10 pack, salvage_pv is called to convert the vtoc 
region for stock operations.) The pvid and Ivid of this disk are 
copied into the pvt, finally making this data valid. The volmap 
and vtoc map are initialized and the stocks made active by 
init_volmap_seg. If this fails, the volume salvager is called 
and we try again. The partition map from the label is checked 
against the volmap to make sure that no partition claims pages in 
the paging region. The updated disk label is written out as we 
ex it. ... ... - 



accept rpv.pll 

The volumes of the rlv are accepted for storage system use 
by accept_rpv. First, the various disks that have hardcore 
partitions are validated, from their labels, to be part of the 
rlv. We then scan the intk card to see if the rpv or rlv desire 
salvaging; these facts are stored in the pvt. If the rpv needs 
salvaging, this is done now ( salvagers volume. salvage) . For 
information purposes, we log (or print, if the hcpt parm was 
specified), the amount of the hardcore partition used on the 
various disks. accept. fs_ disk is called to accept the rpv in the 
normal way. wired_ shutdown is enabled as the storage system is 
considered to be enabled. Appropriately, make_sdw$ reset. hep is 
called to prevent further attempts to allocate from the hardcore 
partition. Contrary to the name ( accept.rpv) , the entire rlv is 
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accepted next by calling the salvager, if 
accept_f s_disk for the other rlv volumes. We 
sal v_data$rpv to keep the salvager from salvaging 



necessary, and 
can then clear 
the rpv later. 



; root dir.Dll 

During a cold bootj the root is 
create_root_dir . It locks the root., setting its 
The various dir header variables are set, pvid, 
etc. A directory style area is set up along 
hash table. The dir is then unlocked and we exit, 



initial ized by 
uid to all ones. 
master_dir flag 4 
with a directory 



create root vtoce. all 

create_root_ vtoce creates a vtoce for the root directory 
during a cold boot. The vtoce created describes the root as a 
master directory of appropriate length , maximum quota limit, 
created as of the current time, primary name of ">", etc. 
vtoc_man is used to allocate space in the vtoc map for this and 
to write it out. 

dj?m m an ,pn 

dbm_man manages the dbm_seg (dumper bit map) for the volume 
dumper. The init entrypoint used during initialization allocates 
and initializes the dbm_seg. Its size is determined from the 
number of disk drives configured and allocated out of the 
hardcore partition by make_sdw. This routine changes dbm_seg 
from its MST status Can abs_seg) to being a real segment. 

dir lock, init »p11 

The segment used to keep track of directory lockings and 
waitings thereupon, dir_ lock_seg, is allocated and initialized by 
dir_ lock_ inid. The size of this segment is based upon 
max_max_el igible (the maximum number of readers of a lock) and 
sys_ info$max_ tree_ depth (maximum lock depth one can hold). The 
dir_lock_seg is converted from an abs_seg to a real seg, paged 
out of the hardcore partition. Initially, ten dir_lock's are 
allocated, threaded appropriately. 

fnp init.Dll 

fnp_init initializes the data bases used in Mul tics- fnp 
communication. tty_buf is allocated in wired memory either with 
a default size or a size specified by the ttyb parm. Various 
header variables are set up. If a tty trace table is called for 
by a conf ig parm, it is allocated in the tty_buf free_ space area. 
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tty_area is initialized as an empty area, tty_ tables also has 
its header filled in and its table.,. area set to an empty area. 
The config file is scanned for fnp cards; each one sets the 
fnp_config_ flags appropriate to it. The hardware fixed 
dn355_mai Ibox for each fnp is zeroed. fnp_info is set. Final ly, 
io_ managers assign is called to assign each fnp with an interrupt 
handler of dn355$ interrupt. 

aetuid.alm 

getuid is the generator of uid's (unique identifiers) for 
storage system objects. Jt operates by effectively incrementing 
tc_data$id under its own form of lock. The init entrypoint used 
during initialization stores an initial uid "seed" in tc_data$id 
generated from the clock, value. 

init branches .Pll 

The program that places the appropriate hardcore segments 
into the hierarchy creating >sl1 and >pdd as it goes, is 
init_ branches. To start with a clean slate, it renames the old 
>process_dir_dir and >pdd to a screech name. append then creates 
a new > pr ocess_dir_dir (added name of >pdd) which is then 
initiated. The per_process sw is set on for this dir. It is 
given the maximum quota possible. The old > system. I ibrary_1 
Osll) is also renamed and a new one created and initiated, 
Access is set to s for *.*.* on it. We then walk down the 
various sst pools looking for segments to have branches created. 
The sst entry leads us to the sit entry for the segment to be 
placed in the hierarchy. create_branch is called (running 
recursively) to create a branch for the segment (it creates all 
necessary containing directories and a vtoce for the segment). A 
pointer to the parent directory and its aste is found. The aste 
for the hardcore segment is threaded into the parent entry. The 
per _ process sw, max_length and uid fields are set in the aste. 
It is then threaded out of the hardcore lists and into the 
appropriate segment list. The vtoc index provided for the 
segment (found in its entry in the parent directory) is copied 
into the aste so vtoc_man will work. The entrybound of the 
segment is placed into the directory entry. If aste tracking is 
going on, a sstnt entry is added. Its vtoce is updated, putting 
the correct information from the initialization created aste into 
the vtoce. The parent directory is then unlocked and terminated. 

The per_process sw is turned on in the aste for >pdd so 
that it can pr opogate down to sons activated off it. We walk 
down >pdd to pr opogate this switch. The maximum length of the 
sit and name^table are explicitly set, not trusting the site 
fields for them. A maximum quota is reset on >pdd. The default 
acl term of sma * . SysDaemon is removed from >pdd and the acl term 
of sma Initial izer, SysDaemon. z is added. > dumps is created and 
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salvaged 
active. 



if needed. The hierarchy is now properly created and 



init dm journal sea. oil 

init_dm_journal_seg initializes the page control data base 
dm_ journal_seg_ used to control synchronous page operations. 
This routine parses the dbmj card. This card describes the sizes 
of the various journals needed. 0nce the size of dm_journal_seg_ 
is found, its memory (wired) is obtained from make_sdw. Various 
header parameters (pool thresholds, pages held, events) are 
filled in, The various journal entries have their time stamp 
initialized to tc_data$end_of_t ime. The various page_entry's are 
threaded into a list. After this, sst$dm_ enabled is set for the 
world to know. 

init hardcore gates .o 11 

ini t_hardcore_gates performs a variety of functions to make 
those things which are hardcore gates into future usable 
entities. It recognizes anything in the sit with ring brackets 
of 0, Oj n as a hardcore gate. It finds within the text (given 
the definitions) the segdef . my„lp and stores there (having 
forced write access) the linkage pointer for the gate. This is 
done because, the gate, known in outer rings by a segment number 
different from the hardcore number , would not be able to find its 
linkage by indexing into the lot by its segment number as normal 
outer ring programs do. Given the segdef . tv_end found for the 
gate, the entrybound is set in the gate's sdw. Finally, the ring 
brackets for restart_f ault and return_to_r ing_0_ are set from 
their sit values so that these segments may be used in outer 
rings with their hardcore segment numbers. ( return. to_r ing_0_ 
has a pointer to it stored as the return pointer in the stack 
frame by signaller. return_to_r ing_0_ finds restart_f ault 
through a text imbeded pointer. ) 



init Ivt.pH 

The logical volume table is 
sets up the header and then uses 
add the entry for the rlv. 



initial! zed by i n i t_ I vt . It 
logical_volume_manager$add to 



init processor- 9 lm 

A processor is ini ted by ini t_ processor. The init 
entrypoint stores the absolute address of various variables into 
in it_ processor itself for execution within absolute mode when 
started on other cpus. When run to start a cpu, it performs some 
collection of tests, enters appending mode, fiddles with associa- 
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tive memories and cache, informs pxss that it is running (through 
its apte) , initializes pds and prds time values, sends out a 
connect to preempt the processor and then opens the mask to allow 
interrupts. (We will be interrupted at this time (by the connect 
we sent). This will cause us to find our way back to pxss to 
schedule something to run on this processor.) The idle loop for 
a processor is contained within init_ processor following this. 
The idle loop flashes a moving pattern in the aq lights when it 
is on the processor. At this time, x4 contains the number of 
eligible processes, x5 the term processid and x6 the number of 
ready processes for the sake of checking system operation. 

in it root dir.Dll 

The root directory is made known by init_root_dir. We 
start by checking to see if this is a cold boot. If so, 
create. root_vtoce is called. The root vtoce is read. An aste is 
obtained for the root dir (64 pages), which is initialized from 
the data in this vtoce. pc is used to fill the page table. 
search_ast hashes in this aste. We can now begin the process 
that wTll allow future segment accessing activity through segment 
control. The Initializer's kst is built, by initial ize_kst. The 
pathname "associative memory" used to map segment numbers to 
pathnames is initialized by pathname_am$ initial ize. makeknown_ 
is called to make the root (uid of all ones) known (found in the 
kst). If this is a cold boot, this segment just made known must 
be initialized to a directory by create_root„dir . Finally, this 
directory is salvaged, if necessary. 

i n i t scavenger- data .oil 

The segment scavenger _ data is initialized by 
i n i t_ sea venger _ data . 

in it sst name seo.pll 

The sst_ names, segment is initialized by init_sst_name_seg 
whenever the astk parm appears. It walks down the sit, looking 
for segments that are paged with page tables in the sst. For 
each, it copies the primary name into the sst_names_ segment. 

in it stack Q.d11 

The various ring zero stacks (stack_0) are created by 
init_stack_0. Since a process cannot lose eligibility while in 
ring~0, the number of processes that can have frames down on ring 
zero stacks is equal to the maximum possible number of eligible 
processes ( max_max_el igible) . We thus create this many ring 
stacks which are used by eligible processes. The various 
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stack._0.nnn segments are created in >sll. They are, in turn, 
initiated, truncated, and prewithdrawn to be 16k. long. The vtoce 
is updated accordingly. The stack header from the initializer's 
ring zero stack. is copied into the header of these stacks. The 
stack is then terminated. The acl for Initializer is removed. 
The first stack slot is claimed for the Initializer; the current 
stack being put into the slot in stack. 0_ data. 

init str sea.pll 

init_str_seg initializes the system trailer segment 
Cstr_seg) into a list of free trailer entries, 

init svs var.pll 

Now that all of the hardcore segments have either been read 
in or created, we can now stand back and observe hardcore. The 
next supervisor segment number (mod 8) becomes the ring stack 
segment number (stack base) which is stored in 
act i ve_al l_r ings_data$stack_base_ segno and hescnt. We make sure 
that the dsegs for the idle processes will be big enough to 
describe these segments. The stack base is stored in the dbr 
value in the apte. Various other system variables are set: 
sys_ inf o$time_of_ boot load, sstSpvhtp (physical volume hold table 
pointer), sstSrqover (record quota overflow error code, which is 
moved to this wired place from the paged error_table_) , and 
sst$checksum_f i lemap (depending on the nock parm) . 

init vol map sea, p 1.1 

ini t_volmap_seg initializes a vol map and vtoc map segment 
allowing us to reference such things on a given physical volume. 
It starts by acquiring an aste for the volmap_seg (for the 
segment abs_seg) and one for the vtoc header (for the segment 
volmap_abs_seg) (vtoc map) which are then mapped onto the desired 
areas of the disk. (This is done under the ast lock, of course.) 
The free count of records is redetermined from the volmap. The 
same is done for the vtoc map. If this is a member of the rlv 
and volume inconsistencies were previously found and the number 
of free vtoces or records is below a certain threshold, a volume 
salvage is called for. If we will not salvage, we can accept the 
disk. Use of the hardcore partition on the disk is terminated 
through a call to ini t_hc_part$ term inate_hc_part. Vtoc and 
record stocks are allocated. The pointers in the pvte to these 
stocks are set as are various other status and count fields. The 
number of free records and the base address of the first record 
in each stock page is computed. The dumper bit map from the disk 
is allocated into the dbm_seg (previously created by 
dbm_man$ ini t_map) . Finally, under the ast lock, we clean up the 
abs_seg and vo I map_ abs_ seg segments (free their sdws) . 
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in it vtoc man.Dll 

The vtoc_ buffer. seg is initialized by ini t_ vtoc. man. This 

routine acquires enough contiguous memory for the 

vtoc_buf f er.seg, determining the number of vtoc buffers either 

from the config vtb parm or from a default. Various vtoc buffer 
headers are initialized here. 

initial ize faults, oil 

ini tial ize_ faults was described earlier under collection 
1. The entry point f ault_ ini t_twOj used by collection 2j sets up 
fault vectors for normal (file system) operations. It prevents 
timer run-out faults during operation through a call to pmut$ldt. 
initial ize.fau Its. data is used to set the main faults. Faults 
set are: command, trouble, segment and linkage to 
f im$pr imary.fault.entry ( scu data to pds$f im_data) , store, mme, 
ftl, lockup, ipr, overflow, divide, df3, mme2, mme3, mme4 and ft3 
to f im$signal_entry (scu data to pds$ signal. data) , and fault 
numbers 26 to 30 to wired.f im$unexp_f ault (scu data to 
prdsSsys. trouble. data) . Access violations are routed specially 
to f i m$ access. violation. entry which maps the acv fault into our 
sub- faults. Timer runouts are sent to wired.f imStimer.runout 
(who normally calls pxss) with the scu data stored in 
prds$f im.data. Parity goes to f im$ par ity_ entry. Finally, we set 
up the static handlers for the no.wr i te.permission, isot.fault 
and lot.fault conditions. 

&3% util ,Pl1 

kst.util performs utility functions with regard to 
maintaining the kst. The garbage collect entrypoint cleans up 
the kst by terminating any segment not known in any ring or a 
directory with no active inferiors. 

start cpu.pII 

start. cpu might best be described as a reconfiguration 
program. It is used during initialization to start a idle 
process on each configured cpu (at the appropriate time). When 
starting the boot load cpu in collection 2, it fills in the apte 
entry for the idle process for the cpu in question. Some more 
variables in ini t.processor 3re set (control ler.data) . A simple 
call out to ini t_processor$start_boot load. cpu can be made. 

svserr log init.pll 

The syserr logging mechanism is made operative by 
syserr.log. ini t. It creates the segment syserr.log which it maps 
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onto the log partition wherever it is. A consistency check is 
made of the partition; if the check fails, the partition is 
re-inited. The syserr hproc ( SyserrLogger . Daemon. z) ' s ring 
stack ( syserr, daemon. stack) is initialized. The hproc is created 
by create.hprocSear ly_hproc with a stack of syserr. daemon. stack, 
dseg of syserr. daemon. dseg, pds of syserr. daemon. pds, and proce- 
dure of syserr. logger. A fast channel is defined for communica- 
tion through syserr. data to the hproc. Logging is now enabled. 

tc init.pii 

tc^init was described earlier to set up and initialize 
tc.data. tc. init$part_2j in collection 2, starts up 
multiprogramming by creating the idle processes. This entry can 
only be called once the initialzer's dseg is completely filled in 
by all those who read or create hardcore segments. Various 
variables in template.pds are filled in which are applicable to 
the idle processes. For each configured processor s a copy of 
template.pds and the initializer's dseg is made into appropriate 
entries in idle.dsegs and idle.pdses. The stack.O for these 
processes is made to be the prds for the given processor. The 
initial process for the bootload processor (the initializer 
himself) is created by threading in an apte specifying 
init. processor as an initial procedure. It is placed in work 
class zero. tcm is initialized to indicate only this one process 
running. Various polling times are set for when polling becomes 
enabled as we start multiprogramming. init. processors init sets 
up the rest of the state. We can now call start.cpu to start the 
bootload cpu idle process. 
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SECTION 7 



COLLECTION 3 



The main task of collection three is to read itself into 
the hierarchy. Collection three consists of those programs that 
are necessary to reach ring one in the initializer's process and 
to be able to perform a reload function (and other maintenance 
functions). A few extraneous functions are also performed in 
collection three. 

ORDER QE. EXEfiUIiaJJ 

Collection three starts with its main function: 
load_system is called to read the remaining mst entities into the 
hierarchy. At this timej the mst reading function is shut down. 

io_conf ig_ init initializes the data in io_conf ig_data for 
use in later econf igurat ion activities, ioi_init is called to 
prep3re for outer ring usage of physical devices. 



tc_ ini t$start_other_cpus starts up the other 
We now consider collection three done 
sys_ info$ init ial ization_ state to 4, 



processors, 
and set 



real_ initial izer finally finishes, returning to 
initializer. initializer can then delete init segs through 
de let e_segs$ init, real_ initial izer being part of one. 
Initialization then finishes by a call to init^proc, to call out 
to ring one command level. 



MODULE DE9CRJPTJPNS 



Unit prog.pn 

init_proc is the first program run in ring zero in a normal 
process. Tt calls out to the initial procedure for a process in 
the outer ring. For the Initializer., the initial_proc is made to 
be system. star t up_ . The setting of the working dir is skipped. 
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since we can't be sure it's there yet, The ring one stack is 
created explicitly, by makestack. system. startup, is initiated, 
cal l.outer.r ing. is called to "return" out to ring one (outward 
calls are not allowed) to transfer to system. startup. . 

io con-Fig init.pll 

io.conf ig_data is initialized by io.conf ig_ init. (It was 
allocated memory and its base pointers set up by get. io.segs. ) 
The tables are initialized in the order: iom and mpc, channel 
and then devices (as it indeed must be). 



Filling in the iom and 
one for one with iom and mpc 



control ler 
cards. 



entries is easyj they are 



A walk is made of prph cards twice. The first pass is made 
to fill in the channel entries. Each prph card is found. If the 
peripheral is a disk or tape (has an mpc) , we also find a chnl 
card (if present). Each channel is added to the channel list. 
The internal routine control ler_ idx_f rom_chan id looks up the 
index into the controller array for the controller owning this 
channel (via ioi.conf ig$f ind. control I er.card) . The internal rou- 
tine iom_ idx_ from. chan id finds the corresponding iom array entry. 
After all of this, each channel is linked to its base physical 
channel via calls to ioi.conf ig$f ind. base. channel . 

A second pass over prph cards is made to f i 1 1 in the device 
entries. For each device, we start by finding its physical 
channels. (This is done by walking down all the channels (from 
the prph and chnl cards), looking up the base channel (from the 
channel entries) and making an array of the physical channels 
found ( tempi ate.pchan.ar ray ) . If any of these channels is 
configured (it was marked configured above because its iom was 
on), the device becomes configured on. The device entry is 
filled in from the card. For disks and tapes, though, we add a 
device entry for the controller and one each for each drive. 



ioi init.pll 

ioi.init sets up the various ioi, 
config deck, allocating group table 
group. Each device whose 
ler has its group entry 
entries and channel table 
on the prph card. Then, 
entry corresponding is 
allocated from the 
logical channel for 



data bases. It walks the 

entries for each channel 

channel is accessed through a control - 

flagged as a psia. The device table 

entries are allocated from information 

for each chnl card, the group table 

channel table entries 

chnl card. The base 

The group entries are 

disk channels. All 



found and the 
information on the 
each group is found, 
find storage system 



then traversed to 

non- storage system disk channels are assigned to ioi. through 
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io_manager. As a final gesture, the ioi_ page tables are setup 
C i o i _ page_ tab I e$ i n i t ) . 

ioi oaae table .oil 

The init entrypoint of ioi_page_table is called during 
initialization to set up the io_page_ tables segment. It starts 
by abs wiring the segment as one page (initially) and zeroing it. 
The header is initialized. Sixty-four word page tables are 
allocated and initialized within this page, as many as will fit. 

load system. oil 

Collection three is loaded into the hierarchy by 
load_system. It reads the mst source C disk_reader ) looking for 
segments. For each, in it_ branches* branch is called to create the 
branch ( init_ branches is described under collection two). The 
appropriate acl is set up, given the mst information. The 
segment contents are copied into the created branch. If the 
Initializer does not have write access to the final segment, the 
acl is cleared of this acl entry. 

ijs_.init.pn 

tc_init was described earlier. The entrypoint 
start_other_cpus, starts cpus other than the bootload cpu at the 
end of collection three (after their interference won't matter). 
A prds for the various non- boot load processors is created and 
entry-held. The pds and dseg for the other cpu's idle processes 
was already created so we can now call star t_ cpu on this new cpu 
as we would normally during reconfiguration. 
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SECTION 8 
MECHANISMS 



This chapter describes certain tricky and not so tricky 
mechanisms used within initialization to get things done. Also 
included is a look at the mechanism by which the various parts of 
the supervisor come into operation. 

HARDCORE SE6MENT EBEAIlffli 

There are various ways that segments come into being within 
the hardcore. These mechanisms are usually quite distinct from 
the normal method of creating a segment within the hierarchy 
( appends foo) . 

The first group of segments that are created are those 
needed by collection zero. Collection zero itself is read in in 
absolute mode; no segments exist other than those hardware 
supplied. To save collection zero the problem of generating 
segments for its use in absolute mode,, its segments are generated 
by macros within template_slt_. aim. These macros generate not 
only the sit entries for collection zero segments (and various 
segments at fixed absolute memory addresses); they also generate 
the page tables and the segment descriptor words for the 
segments. A much simpler program in absolute mode moves these 
page tables and sdws (the dseg) to appropriate places and loads 
the dbr (also generated by template„slt_) . Thus, these early 
segments come quickly and magically into being. All of the 
segments described by the template_slt_ are data segments with no 
initial content except for bound_bootload_0 itself , which was 
loaded into the correct memory address by the boot load tape 
label j and toeholdj by virtue of being the first part of 
bound_ boot I oad_ . 

The second group of segments to come into being are the 
collection one segments loaded by collection zero. These seg- 
ments are created through a mechanism imbeded in boot I oad_ loader 
and bootload_dseg. When the segment header (actually a sit 
entry) is read from the MST, the need for a segment of a certain 
size is called for. Values in the sit header keep track of the 
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extent of memory allocated. The type of segment (permanent 
"unpaged" or not) determines from what end of memory the space 
will be obtained. A page table of appropriate size is 
constructed in the proper area (either the segment 
unpaged. page_ tables for permanent "unpaged" segments or 
int_unpaged_page_ tables for temporary or to be made paged seg- 
ments) . A new sdw pointing to this page table is tacked onto the 
appropriate end of dseg (low segment numbers for permanent 
segments, high for temporary or init segs) . With write access 
set on in this sdw, the segment contents can be loaded from tape 
into the memory area, Proper access is then set in the sdw. The 
segment is now existent. 

Collection one creates certain data segments that are wired 
and contiguous. The most obvious is the sst. These are created 
by the routine get_main, get_main might be considered the 
counterpart of the collection zero segment creation mechanism 
when called in collection one. It also allocates memory space 
from values in the sit header. A page table of appropriate 
length in one of the two unpaged page table segments is 
constructed and a sdw fabricated to this page table. The caller 
of get_main forces this sdw into dseg and performs the appropri- 
ate associative memory clearing function. 

The other type of segment created by collection one is a 
paged segment. There are two cases of this. The first is a 
paged segment that is to be mapped against a previously defined 
area of disk. This is done when we want to access a partition or 
part thereof j as when we want to read the config deck from disk. 
To do this, make_sdw is called., specifying that we want an sdw 
for an abs-seg. make„sdw finds us an aste of appropriate size 
and threads it into the hardcore lists, but senses the abs-seg 
switch and does not allocate pages or whatever. The caller of 
make_sdw builds its own page table within the aste obtained by 
calling ptw_ut i l_$make_disk to make each page table word point to 
the correct disk record. The pvtx of the desired disk is 
inserted into the aste. Thus, references to this segment (whose 
sdw points to the page table in this aste) will wake up page 
control who will page in the proper pages. This mechanism 
appears in several places; the desired way of generating such a 
segment is to call map„onto_disk. 

The second type of paged segment created by collection one 
(or two for that matter) is a segment paged off the hardcore 
partition. In this case, allocation of pages is done by page 
control. make_sdw is called as before, but, this time, it not 
only creates an aste for the segment, but it finds space for it. 
A disk with a hardcore partition with enough free space to hold 
the segment is selected. This pvtx is put into the aste. As an 
added bonus, since such segments will not have trailer entries, 
the trailer pointer in the aste is set to the hardcore segment 
number ( for those programs that need to map the hardcore aste 
list entries to sit entries). The page table words are set to a 
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nulled state. make_sdw then touches each page, causing page 
control j when the page fault occurs., to withdraw a page from the 
partition. ( init_hc_part created a vol map and record stock that 
page control can use which describes only the hardcore parti- 
tion,) With the segment now in existence, the caller of make_sdw 
can now load the segment. For collection one or two, this 
involves either initializing the data segment or copying in the 
segment contents read from the mst. 

When collection two needs a wired contiguous data space., it 
calls get_main also. In this case, though, get_main calls 
make_sdw$ unthreaded which will obtain an aste and sdw and page 
space. pc_abs$wire_abs_cont ig is then called to wire this 
segment into contiguous memory pages. A paged segment to be 
mapped onto a particular area of disk is created as described for 
collection one. 

Hardcore segments that need to be placed into the hierarchy 
(deciduous segments) are so placed as follows. append is called 
to create a branch, This creates a vtoce for the segment and 
makes active, creating if necessary, all parent directories. 
Normally, segment control activities would then create an aste 
for this being created segment which would be threaded as a son 
of the parent directory's aste. In this initialization case, 
though, the aste for the new segment already exists. We hand 
thread this aste into the normal segment lists and thread it as a 
son of the parent directory's aste. The directory entry for this 
segment created by append gives the vtoc index of the vtoce for 
it. By placing this vtocx into the old aste for the new segment, 
vtoc_man can make the vtoce for this now deciduous segment 
reflect the placement of this segment in the hardcore partition 
(where it was allocated during hardcore initialization). The 
segment is now properly active and accessible from the hierarchy. 

HARDWARE AJffi CONFIGURATION 1HJTI AUZATIPN- 

The initialization of the hardware and configuration infor- 
mation pertaining to it (basically scs (and also iom_data)) is a 
little understood process. To better understand the method of 
initialization, it is necessary to start with an understanding of 
the operation of the hardware on which Multics runs. This 
description pertains to the DPS- 8 hardware series. The descrip- 
tion for the Level-68 series is similar but is not included. 

I nterconnect i on of Multics hardware 

A Multics system consists of a set of system control units 
(SCU's), central processing units (CPU's) and input/output 
multiplexors (IOM's). 
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A SCU controls access to memory. Each SCU owns a certain 
range of (absolute) memory. Any active unit (a CPU or an IOM) 
that requires access to memory does so by requesting the access 
from the SCU that owns the given range of memory. 



A CPU 
It operates 
priate SCUs,, 
appropr i ate 



performs the actual computations within the system, 
by requesting instructions and data from the appro- 
operating upon them, and placing the results into 
locations in SCUs. 



An IOM performs input and output to physical devices. It 
requests data from SCUs to send to devices and takes data from 
devices, storing it into SCUs. 

IQMs and CPUs are not directly connected to one another. 
The only method of communication between active modules is 
through a SCU. The connection of modules in a Multics system is 
therefore something like the following. 



IOM A 



I IOM B 






I MEM A I 1 SCU A 1 






SCU B 



I 



--1 MEM B 



CPU A I I CPU B I 



The crosses indicate that both IQMs and both CPUs connect 
to both SCUs; the CPUs and IQMs are not themselves connected. 

The active modules (CPUs and IQMs) have up to four ports 
that go to SCUs. These are referred to as the memory ports of 
the active module in question. The SCUs have up to eight ports 
that can go to active modules. These are 
active module ports of the SCU or just simply 



referred to as 
as SCU ports. 



the 



All CPUs and IQMs must share the same layout of port 
assignments to SCUs. Thus, if memory port B of CPU C goes to SCU 
Dj the memory port B of all other CPUs and IQMs must go to SCU D. 
All CPUs and IQMs must describe this SCU the same; all must agree 
in memory sizes. Also, all SCUs must agree on port assignments 
of CPUs and I ©Ms. Thus, if port 3 of SCU C goes to CPU A, then 
port 3 of all other SCUs must also go to CPU A. 
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Configuration &£. Mult ics hardware 

The various hardware modules need varying amounts of 
configuration description information with which to run. 

CPU AND IOM HARDWARE CONFIGURATION 

The CPUs and IOMs require access to main memory. They 
resolve their own internal concept of memory address (virtual or 
io page table) into an absolute main memory address. This 
address must describe a location in one and only one memory store 
unit., which itself must foe connected to only one SCU. The IOM or 
CPU must determine which SCU owns the memory location desired, 
and supply that SCU with the address relative to its base of the 
location desired. The CPU and IOM do this with the memory 
configuration information Known to them by configuration switches 
and changed under software control. 

The configuration data Known to the processor (at the 
hardware level) is found via the rsw instruction with operands of 
1 and 2, which can be obtained by calling pmutSrsw with these 
operands. The format of the data returned is described in 
rsw. incl.pll and also shown below. 

The data returned by the rsw 2 instruction is shown below. 

bits meaning 

0-3 4- word/ 2- word interlace ( if enabled) 

4-5 processor type (01 for DPS-8) 

6-12 seven msb's of the fault base 

13-13 id prom installed 

19-19 dps (marKeting) option 

20-20 8K cache option 

23-23 Multics model CPU 

24-24 Multics mode enabled 

29-32 cpu speed (0 = 8/70, 4 = 8/52) 

33-35 cpu number 

The data returned by rsw 1 consists of four nine bit bytes 
describing each of the four possible memory (SCU) ports of the 
processor. The bytes appear in order in the result, SCU in the 
high order bits. The format of the byte is: 

bits meaning 

0-2 port assignment 

3-3 port is enabled 

4-4 system initialize is enabled 

5-5 port is interlaced with neighbor 

6-8 memory size 
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The actual memory size of the memory attached to the SCU attached 
to the processor port in question is 32K * 2 ** (encoded memory 
size). The port assignment couples with the memory size to 
determine the base address of the SCU connected to the specified 
CPU port (absolute address of the first location in the memory 
attached to that SCU). The base address of the SCU is the 
(actual memory size) * (port assignment). 

The ISM has similar port description information 
interpreted similarly. This information is not readable from the 
CPU. 



SCU HARDWARE CONFIGURATION 

The SCU also has description of its ports (to CPUs and 
IOMs) as well as description of the store units attached to it. 
This information is determined by the rscr instruction 
(pmut$rscr)j given the SC_CFG argument. (The explanation of the 
rscr instruction appears later.) The portions of the result that 
pertain to SCU port and store unit configuration sre shown below. 

bits meaning 

09-11 lower store size 

12-15 store unit ( A A1 B B1 ) on-line 

21-21 SCU in program mode ( vs manual) 

22-22 non-ex istant address checking enabled 

23-29 non-existant address limit 

30-30 store unit interlace enabled 

31-31 B is lower addressed store ( vs A) 

32-35 port enable mask for ports 0-3 

57-63 cyclic priority (0/1-6/7) 

68-71 port enable mask for ports 4-7 

A DPS-8 SCU may have up to four store units attached to it. 
If this is the case, two store units form a pair of units. The 
size of a pair of units (or a single unit) is 32K * 2 ** (lower 
store size) above. 

If the non-existant address flag is on, any address to a 
store unit whose high order bits (above the lower 15) is greater 
than or equal to the non-existant address limit generates a 
non-existant address SCU illegal action. 

A SCU will respond to and provide information to only those 
ports that are enabled (port enable mask above). 

SCU ADDRESSING 

There are three ways in which an SCU is addressed. In the 
normal mode of operation (memory reading and writing) s an active 
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unit (ISM or CPU) translates an absolute address into a memory 
port (on it) and a relative memory address within the memory 
described by the memory port. The active module sends the 
address to the SCU on the proper memory port. If the active 
module is enabled by the port enable mask in the referenced SCU, 
the SCU will take the address given to it and provide the 
necessary memory access. 

The other two ways pertain to reading/sett ing control 
registers in the SCU itself. For each of these, it is still 
necessary to specify somehow the memory port on the CPU whose SCU 
registers are desired. For the rmciHj smcm and smic instructions, 
this consists of providing a virtual address to the processor for 
which bits 1 and 2 are the memory port desired. 



The rscr and sscr instructions, though, key off the final 
absolute address to determine the SCU (or SCU store unit) 
desired. Thus, software needs a way to translate a memory port 
number into an absolute address to reach the SCU. This is done 



with the paged segment seas, generated by 
init_scu). seas has a page corresponding to each 
store unit in each SCU. pmutSrscr and pmutSsscr 
port number desired to generate a virtual address 
absolute address (courtesy of the ptws for seas) 
describe memory within that SCU. 



init_scas (and 
SCU and to each 
use the memory 
i nto seas whose 
just happens to 



The cioc instruction (discussed below) also depends on the 
final absolute address of the target operand to identify the SCU 
to perform the operation. In the case of the cioc instruction, 
though, this has no particular impact in Multics software. All 
target operands for the cioc instruction when referencing IQMs 
are in the low order SCU. When referencing CPUs, the SCU 
performing the connecting has no real bearing. 



As mentioned earlier, communication between active modules 
(CPUs and IOMs) can only be performed through SCUs. 

CPUs communicate to IOlis and other CPUs via the cioc 
connect i/o channel) instruction. The operand of the instruction 
is a word in memory. The SCU containing this operand is the SCU 
that performs the connect function. The word fetched from memory 
contains in its low order bits the identity of a port on the SCU 
to which this connect is to be sent. This only succeeds if the 
target port is enabled (port enable mask) on the SCU. When the 
target of the connect is an IOM, this generates a connect strobe 
to the I5M. The I0M examines its mailbox in memory to determine 
its course of action. When the target of the connect is another 
CPU, this generates a connect fault in the target processor. The 
target processor determines what course to follow on the basis of 
information in memory analyzed by software. When a connect is 
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sent to a processor ( including the processor issuing the con- 
nect) j the connect is deferred until the processor stops 
executing inhibited code (instructions with the inhibit bit set). 

Signals sent from an IOM to a CPU are much more involved. 
The basic flow is as follows. The IOM determines an interrupt 
number. (The interrupt number is a five bit value, from to 31. 
The high order two bits are the interrupt level. 

- system fault 

1 - terminate 

2 - marker 

3 - special 

bits determines the IOM and IOM channel 



The 


low 


order three b 


group. ) 








- 


IOM 





channels 


32-63 


1 - 


IOM 


1 


channels 


32-63 


2 - 


IOM 


2 


channels 


32-63 


3 - 


IOM 


3 


channels 


32-63 


4 - 


IOM 





channels 


0-31 


5 - 


IOM 


1 


channels 


0-31 


6 - 


IOM 


2 


channels 


0-31 


7 - 


IOM 


3 


channels 


0-31 



It also takes the channel number in the group (0-31 meaning 
either channels 0-31 or 32-63) and sets the <channel number>th 
bit in the < interrupt number >th memory location in the interrupt 
mask word ( IMW) array in memory, It then generates a word with 
the < interrupt number>th bit set and sends this to the boot load 
SOU with the SXC (set execute cells) SOU command. This sets the 
execute interrupt cell register in the SCU and sends an XI P 
(execute interrupt present) signal to various processors 
connected to the SCU. (The details of this are covered in the 
next section.) One of the processors (the first to get to it) 
sends an XEC (execute interrupt cells) SCU command to the SCU who 
generated the XI P signal. The SCU provides the interrupt number 
to the processor, who uses it to determine the address of a fault 
pair in memory for the "fault" caused by this interrupt. The 
processing of the XEC command acts upon the highest priority 
(lowest numbered) bit in the execute interrupt cell register,, and 
also resets this bit in the register. 



Interrupt Masks 

The mechanism for determining which processors are candi- 
dates for receiving an interrupt from an IOM is an involved 
topic. First of all, a processor will not be interrupted as long 
as it is executing inhibited instructions (instructions with the 
inhibit bit set). Beyond this, though, lies the question of 
interrupt masks and mask assignment. 
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Internal to the SCU are two sets of registers (A and B) , 
each set consisting of the execute interrupt mask register and 
the interrupt mask assignment register. Each execute interrupt 
mask register is 32 bits long, with each bit enabling the 
corresponding bit in the execute interrupt cell register. Each 
interrupt mask assignment register has two parts, an assigned bit 
and a set of ports to which it is assigned (8 bits). When a bit 
is set in the execute interrupt cells register , the SCU ands this 
bit with the corresponding bit in each of the execute interrupt 
mask registers. If the corresponding bit of execute interrupt 
mask register A, for example, is on, the SCU then looks at the A 
interrupt mask assignment register. If this register is not 
assigned (enabled), no further action takes place in regards to 
the A registers. (The B registers are still considered (in 
parallel , by the way).) If the register is assigned (enabled), 
then interrupts will be sent to all ports (processors) whose 
corresponding bit is set in the interrupt mask assignment 
register. Thus, only certain interrupts are allowed to be 
signalled at any given time (based on the contents of the execute 
interrupt mask registers) and only certain processors will 
receive these interrupts (as controlled by the interrupt mask 
assignment registers). 

In Multics, only one processor is listed in each of the two 
interrupt mask assignment registers, and no processor appears in 
both. Thus, there is a one for one correspondence between 
interrupt masks that are assigned ( interrupt mask registers whose 
assigned (enabled) bit is on) and processors who have an 
interrupt mask (SCU port number appears in an interrupt mask 
assignment register). So, at any one time only two processors 
are eligible to receive interrupts. Other processors need not 
worry about masking interrupts. 

The contents of the interrupt mask registers may be 
obtained with the SCU configuration information with the rscr 
instruction and set with the sscr instruction. 

bits meaning 

00-07 ports assigned to mask A ( interrupt mask assignment A) 

08-08 mask A is unassigned (disabled) 

36-43 ports assigned to mask B ( interrupt mask assignment B) 

44-44 mask B is unassigned (disabled) 

The contents of a execute interrupt mask register are 
obtained with the rmcm or the rscr instruction and set with the 
smcm or the sscr instruction. The rmcm and smcm instruction only 
work if the processor making the request has a mask register 
assigned to it. If not, rmcm returns zero (no interrupts are 
enabled to it) and a smcm is ignored (actually, the port mask 
setting is till done). The rscr and sscr instructions allow the 
examining/ sett ing of the execute interrupt mask register for any 
port on a SCU; these have the same effect as smcm and rmcm if the 
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SCU port being referenced does not have a mask assigned to it. 
The format of the data returned by these instructions is as 
f ol lows, 

bits meaning 

00-15 execute interrupt mask register 00-15 

32-35 SCU port mask 0-3 

36-51 execute interrupt mask register 16-31 

68-71 SCU port mask 4-7 

Q perat i ons upon masks 

Since at most two processors have interrupt masks assigned 
to them, not all processors can manipulate their own masks. But., 
to remove the need for processors to ask whether they have a mask 
before operating upon them (in partiuclar, to mask interrupts); a 
mechanism has been devised. It's execution is carried out by by 
pmut$set_mask and pmutS read. mask. The code fragment of pmut that 
reads/ sets the mask follows. 



readmask: 



set_ mask : 



1x11 prdsS processor. tag 

Iprpab scs$mask_ptrj xl 

x ec scs$r ead_ mask , x 1 



1x11 prds$processor_tag 

I pr pap scs$ mask_ ptr , x 1 

xec scs$set_maskj xl 



For each processor tag, thenj there is a set of data pointers and 
instructions in scsSmask^ptr, scs$read_mask and scs$set_mask that 
either operate upon the processor's mask or pretend they did. 
When the processor in question does not have an interrupt mask, 
the data is as follows: 

mask_ptr - packed pointer to 
pr ds$ s i mu I ated_mask 

read_mask: 

1 daq ab 1 

set„mask: 

staq ablO 

which will succeed in doing nothing. When the processor does 
have an interrupt mask, the data is as follows: 

mask_ptr - packed pointer to 

scs$ por t_ address i ng_ wor d( boo 1 1 oad scu ) 
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read_mask: 

rmcm abl 0, * 

set_mask: 

smcm abl Oj * 

which will read and set the mask. The array 
scsSport. addressing. word contains the data words required as 
operands for the rmcnij smcm and smic instructions. They contain 
the memory port number in their low order bits Ci.e.j their array 
index is their contents). The smic instruction uses 
scs$ interrupt. control ler (the low order memory port (address 0)) 
as ian array index to perform the smic against the low order SCU. 

The operands of the pmut$ read. mask and pmut$set_mask opera- 
tions (rmcm and smcm instructions, respectively) were described 
above. The value scsSsys.level masks all interrupts. It has 
zeroes for all bits loaded into the execute interrupt mask 
register but has all ones for all ports of the SCU to which 
enabled active modules are connected. scsSopen. level has the 
same SCU port enable bits but has ones for all interrupts of all 
levels from both channel sets of all IOMs currently active. 



Configuration initialization occurs primarily within 
scs_and_ clock_ ini % t iom.data. init, scas_init and init_scu called 
from within scas_init. 

The name of this routine should probably be just scs_init. 
The clock portion is really just a check of clock functioning 
(and setting up clock data in general). It fills in the 
scsSport.addressing.word" s as described above. 
scs$ processor. switch. data is read to get the configuration and 
data switch values. scs$bos_processor.tag is set to indicate 
this cpu (currently the only one running) as the bootload cpu. 
scs$ read. mask, scs$set_mask and scs$mask_ptr are set to the dummy 
values mentioned above, When scs_and_clock_ init is run ; all 
interrupts are masked, and no one really needs to think about its 
masks. The various processor ports are examined looking for 
memories. The port number of the low order memory so far is set 
into scs$ interrupt. control ler and sys_ info$ clock. . When 
scs_ and. clock. init is finsihed, then, the configuration data for 
the bootload cpu is known, as well as for the various memories 
attached to it. Examination of this data and setting of masks 
waits for later programs. 

i om_ data. ini t initializes the data needed by io_ manager. 
This includes descriptions of the various IOMs and their chan- 
nels. The basic setup of this information (numbers of IOMs, 
numbers of channels) was set up by get.io.segs who obtained this 
data from the config_deck. Most description of IOMs appears in 

8-11 AN70-01 



iom_data so no major changes take place to scs within 
iom_data_ ini t. 

Aside from filling in sew's and Ipw's for each 
channel_table and mailbox entry, the more interesting part of 
i om_ data_ i n i t is the main IOM card processing loop. It examines 
each IOM card, making sure that no IOM is duplicated, that the 
field values are reasonable, that no card claims an SCU port 
claimed by another IOM (and sets scs$port_data to claim the IOM) 
etc. The iom_data. per_ iom data is initialized as to configured, 
on_line, paged, etc. This routine adds to scs$open_ level the 
necessary bits to enable interrupts from the lOMs, (Interrupts 
are not enabled until ini tial ize_faulst$ interrupt. ini t. ) 

The conclusion of configuration initialization occurs in 
scas_init and its servant, init_scu. At its entry, scs$port_data 
has been set up to only describe the IOMs. This routine will set 
these for processors. It also initializes seas, as its name 
implies. This requires determining all memories and store units. 
Aside from this, the routine checks the port enable switches for 
the processor ports for correctness. 

The first loop of interest scans all CPU cards. It checks 
them for reasonableness, that no CPU is mentioned twice, that no 
other active module claims this SCU port, etc. The cow's 
(connect operand words) used when perfoming cioc's to this 
processor are set. 

What follows this is the SCU scanning loop. It takes each 
MEM card and checks it for reasonableness, whether tags are 
duplicated, whether the memory extent (from rsw_util) matches and 
does not overlap any other memory, etc. init_scu is then called. 

init_scu initializes an SCU. This is the routine that sets 
up seas for a particular SCU. This is done by installing ptw's 
into the page table for seas to describe the SCU. Reading the 
configuration from the SCU, the data is compared against the 
computed data given the processor configuration information 
(which scas_init compared against the config_deck description of 
the memory). If the configuration from the SCU indicates 
aditional store units, the seas pages for them are set (to allow 
getting the store unit mode registers with an rscr). 

The mask checking part of init_scu makes sure that each 
interrupt mask that is assigned on the SCU is assigned to a 
processor (as opposed to an IOM) and that no more than one mask 
indicates a given processor. This is done by walking down the 
CPU data in scs and comparing the mask data recorded for the 
other processor ports for duplication. This also records which 
masks assigned for this SCU are claimed by processors. Any mask 
that is assigned that does not appear in the description of a 
pr ocessor is mis- ass i gned . 
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After the SCUs have been initialized in this way, a little 
more work is left. The bootload CPU's ports Bre checked, so that 
no extra port is enabled. For each IOM (and the bootload CPU), 
the port enable bit is set in each SCU. 

For each processor, we find the processors with masks 
assigned. For these, we set scs$set_mask, scs$read_mask and 
scs$mask_ptr to actually perform the rmcm and smcm instructions 
as described above to manipulate their masks. We check to be 
sure that the bootload CPU owns one of the masks. 

The final loop examines the ordering of active modules on 
the SCUs to see if the cyclic priority switches can be set. This 
is only done if the IOM group does not overlap the CPU group. 

PAGE CONTROL JJj] TI AH £ATI ON 

Page control initialization consists of a variety of 
activities run during collection one. init_sst build the sst and 
core_map. The sst is needed since we need to have an aste for 
page control so that it can find what disk needs i/o (from the 
pvtx within the aste). The core_map is needed since it shows the 
status of memory pages (initially free between the groups of 
initialization segments, currently wired). Page control needs 
this information so it can find a free memory frame into which it 
can read a desired page. init_pvt performs the function of 
creating the pvt. It is the index into the pvt for the device 
from which a page (or other i/o) is desired that is needed by 
disk_ control (dctl). read_disk$ ini t is needed to initialize page 
reading/ writing through rdisk_seg. This routine builds the paged 
segment rd isk_seg, which can be mapped onto the desired page of 
disk to read. The aste for rdisk_seg contains the pvtx of the 
disk to read. The page table word for rdisk_seg provides the 
disk address. At this point, we can actually read or write a 
page by touching rdisk_seg within read_disk. read_disk sets up 
the aste and page table word, as described. When the page is 
touched, a page fault will wake up page control. It will find a 
free memory frame, read the page in, and resolve the page fault. 

read_disk_ label uses read_disk, then, to read a disk label, 
ini t_root_vols uses read_disk_ label to read the label of hardcore 
partition volumes. Given the label, it finds the partition map 
and finds the hardcore partition. A small vol map is built that 
describes this partition and is mapped onto the beginning of the 
partition. A small record stock is built to describe the volmap. 
Given this initial stock, attempts to create or free pages on a 
disk (within the hardcore partition) can succeed. Now, we can 
create hardcore segments by building null page tables and taking 
page faults. Page control will find a free page from the volmap 
for the partition (whose pvtx is in the aste) and resolve our 
page fault. At this point, all of the services we need of page 
control are available. For the ease of later activities who need 
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various partitions to map paged areas onto,, ini t_part i t ions is 
called to validate the part information. We now page happily. 

Later j in collection two, the real vol maps and record 
stocks are set up by accept_rpv. After this point, page control 
will simply shift its page creation/ freeing activity to that 
described by the paging region. All hardcore segments had their 
pages pre- withdrawn from the hardcore partition, so no possibili- 
ty exists that we will accidentally put a paging region page into 
a hardcore segment. 

SEGMENT AND DIRECTORY CBNTRQL } N? J\ Ati NATION 

Segment and directory control are initialized in stages 
throughout collections one and two. It started in collection one 
when the sst was built. It continues into collection two with 
getuid$init. This allows us to generate unique ids for newly 
created segments and directories. ini t_vtoc_man paves the way 
for vtoc_man to perform i/o on vtoces. Segment control's trailer 
segment is created by ini t_str_seg. accept_rpv sets up the real 
vtoc maps and vtoc stocks. Now vtoc_man can really read and 
write vtoces, as well as create and free them. Now, if we were 
to try a normal activation of a segment, given its pvtx/vtocx, we 
could find the segment and thread the segment into the right 
astes and trailers. init_lvt builds an initial rlv (in the Ivt) 
out of the disks listed as having hardcore partitions. This 
allows segment control's disk selection algorithm to be able to 
find a disk to use when segments try to be created. We now have 
enough mechanism in place to utilize most of the facilities of 
segment control, but we cannot yet access and activate hierarchy 
segments. 

The initialization of directory control is imbedded within 
the initialization of segment control. It started with 
dir_ lock_ init providing us with an ini tial ly empty I ist of locked 
directories. The real start up of directory control, though, 
occurs in ini t_root_dir . This builds the kst (used at segment 
fault time to resolve segment numbers into an understanding of 
what needs activation) and creates ( if need be) and activates and 
initiates by hand the root directory. Directory control can now 
reference hierarchy objects with segment control's help. Any 
attempt to create a hierarchy segment (append) can succeed by 
selecting a disk (Ivt lookup), vtoce creation (vtoc_man using 
vtoc stock, vtoc map and vtoc buffers) and aste creation (using 
sst and the trailer seg) . Also, deactivation is possible since 
the trailer is built to describe what to setfault and the kst is 
present to be able to re-activate. At this point, we are able to 
handle segment faults, given the information in the kst and by 
recursively traveling down the hierarchy by virtue of the fact 
that the root is now and always active. 
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NUMBER ASSIGNMENT 

There are basically three classes of segments as far as 
segment number assignment is concerned. The first is segments 
that will be a permanent part of the supervisor. These are 
assigned consecutive segment numbers, starting at 0. dseg is 
always 0, of course. 

The second class is initialization and collection temporary 
segments. These are assigned consecutive numbers starting at 400 
octal. Although temporary segments are deleted at the end of 
each collection, their numbers are not re- used. We continue to 
assign the next non-used number to the next temporary or 
initialization segment. 

The order of assignment of these numbers is purely 
according to the order that the segments are encountered. The 
first few segments are assigned numbers by template_slt_j but, 
again, this is in order of encounter ance. The only requirements 
are that dseg must be segment and that the sit must be segment 
7 (assumed by all dump analyzers). 

Normal hierarchy segments fall into the third class of 
segments, as far as segment number assignment is concerned. As 
for these, the sequence is as follows. The next higher mod 8 
segment number after the last permanent supervisor segment is 
chosen as the stack base (ring zero stack number). The next 
seven numbers are assigned to the outer ring stacks, in order. 
Since the root is made active after this, and the root becomes 
the first real hierarchy segment initiated, it gets the segment 
number after stack_7. Other segments are assigned progressively 
higher segment numbers according to segment control's normal 
rules. We do not need to worry about running into segment number 
400 octal since these segments will be deleted before we ever get 
that far, Only permanent supervisor segments will show up in 
one's dseg. 

Some supervisor segments (deciduous segments) get initiated 
into the normal user's address space. Regular stacks are 
initiated by special handling (makestack called from the segfault 
handler) and are directly referred to by the reserved stack 
segment numbers. A normal segment like bound_ I ibrary_l_ is 
activated through normal segment control means. Thus, it will 
appear in two places in the user's address space; one in the 
supervisor segment number range (with ring brackets of 0, 0, 0, 
by the way) and once in the user ring segment number range 
(greater than the root's segment number) (with ring brackets of 
0, n, n) . 

This is a problem for hardcore gates, though, relative to 
their linkages. A user ring call to bound. I ibrary_l_ will cause 
modules within it to find their linkage section from the lot 
entry for this segment. Any module called from bound_l ibrary_1_ 
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will also be in the user ring, so the user ring linkage section 
for the segment number corresponding to the user ring version of 
bound_l ibrary_l_ will find the called module. Hardcore gates, 
however, don't call hierarchy entities but instead call entities 
that can only be found through the linkage section generated via 
pre- 1 inking during initialization which resides in the ring zero 
linkage section corresponding to the hardcore segment number. To 
make it possible to find this easily, ini t_hardcore_gates stored 
into the hardcore gate segdef .my_lp the pointer to this linkage 
section. Thus, when called from the outer ring with the outer 
ring segment number, hardcore gates will quickly switch over to 
the hardcore linkage section and function properly. 

TRAFFIC CQNTRQL JNI TI All ZATJON 

All three collections contribute efforts toward enabling 
traffic control. Collection one starts by building the tc_data 
segment in tc_init, full of empty aptes to describe processes. 
At this time, though, a flag in tc_data indicates that 
mult- programming is not active. Any call to traffic control to 
pxssSwait will simply loop for notification (which will come from 
a call to pxssSnotify in some interrupt routine). No polling 
routines are run at this time. Other initialization activities 
proceed to build the supervisor address space, 

Collection two starts up multi -programming. It does this 
through tc_ ini tSpart_2. Mult i -programming requires 
multi-processesj initially this is the Initializer and an idle 
process, but it soon encompasses answering service created 
processes and hardcore processes (hprocs). Creating an idle 
process requires creating a pds, stack_0 (prds) and dseg for it. 
The dseg and pds are simply copies of those for the Initializer, 
now that they are filled in. apte entries for the Initializer 
and for idle are created. We can now consider mult i -programming 
to be on. start_cpu is called to start the processor. For the 
boot load' processor, this means calling ini t_processor in a 
special case environment (non-absolute mode, if nothing else). 
init_ processor (the idle loop) marks itself as a running 
processor, sends itself a connect, and unmasks the processor. 
The connect will go to traffic control, who will pre-empt idle 
and return control to Initializer. 

In collection three, start_cpu is called (from 
tc_ ini t$start_other_cpus) in the same manner as would be done for 
adding a cpu during reconfiguration. This is somewhat described 
in the reconfiguration manual. 
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SECTION 9 
SHUTDOWN AND EMERGENCY SHUTDOWN 



The goal of shutdown., obviously enough, is to provide an 
orderly cessation to service. A normal shutdown is one in which 
the system shuts itself down, following the direction of the 
operator's "shut" command. An emergency shutdown is that opera- 
tion ipvoked by bee which forces Multics to run 
emergency„ shutdown, which performs the clean up operations below. 

One could consider the system to be shutdown if one simply 
forced a return to bee, but this is not enough. Proper shutdown 
involves, at first, the answering service function of logging out 
all users. The answering service then shuts itself down, 
updating final accounting figures. Now with just the Initializer 
running, the task of shutdown described here follows. 

The major goal of shutdown and emergency_shutdown is to 
maintain consistency of the storage system. It is necessary to 
move all updated pages of segments to disk., to update all 
directories in question with new status information, to update 
vtoces of segments referenced, and to clear up any effects caused 
by the creation of supervisor segments. 



These functions must be performed in several stages. Also, 
the ordering of operations is such as to minimize the degree of 
inconsistency within the storage system that would occur if a 
failure were to occur at any point. 

Since these same functions are performed for an emergency 
shutdown, the operations are performed so as to assume as little 
as possible from the information in memory. 

ORDER Ofi EXECUTION fiE SHUTDOWN 

The module shutdown is called via hphcs_$ shutdown. It 
starts by removing the fact that we were called from an outer 
ring, so we won't accidentally return. An any_ other handler is 
set up to flag any possible error, later. The first action of 
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shutdown is to force itself to run on the boot load cpu and to 
stop the others Cstop_cpu). 

disk_emergency$test_al l_dr i ves checks out all of the stor- 
age system drives at once to avoid errors later. 

tc_shutdown destroys the remnants of any processes and 
turns off mult i -processing. 

scavengers shutdown cleans up any scavenges that were in 
progress. 

We then switch over to the stack inzr_stkG for the rest of 
shutdown. This is performed through the aim routine, 
switch, shutdown., f i le.systerij which starts the file system shut 
down . 

shutdown_f i le_ system is the first program called on 
inzr_stkO. It is a driver for the shutdown of the file system. 
It starts by updating the rp\f vol map, vtoc header (and vtoc map) 
and label of the rpv to show the current state ( in case problems 
occur later) . 



The most important step, from the user's point of view 
to flush all pages in memory (considered to be 
shutdown) with pcSflush. This is relatively easy 
perform since it only requires walking down core map 



is 

part one of 

and safe to 

entries; sst 



threads, etc, 
completion of 



do not 
( emergency) 



have to be trusted, 
shutdown, part 1 . 



This marks the 



The stack 
deact i vate them 



zero segments are released so that demount^pv can 



deact ivate_for_ demounts shutdown deactivates all 
non- hardcore segments and reverts deciduous segments (removes 
from the hierarchy those supervisor segments put into the 
hierarchy during initialization). This updates the directories 
containing those segments that were active at shutdown time (and 
their vtoces) . 



Our next task is to remove the pages of 
directories from memory. We start by demounting 
disks (other than the rpv) with demount_pv. After 
locks remain set, we set the shutdown state to 
normal ly four. 



these updated 

all operative 

this, if any 

threej it is 



If any disks are inoperative, we just perform another 
memory flush (to remove rpv directory pages), wait for console 
i/o to finish ( ocdcm_$drain_ io) and return to bee. 



If all was okay, we demount the 
storage system is now considered to be 
in the flagbox is reset to show this. 



rpv with demount_pv. The 
shut down. The ssenb flag 
We flush memory once more, 
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to get the last log messages out. The message "shutdown 
complete" is printed; we wait for console completion. Shutdown 
can now return to bee. 

ORDER QE EXECUTION OJF EM E RGENCY S J-lUTpeWN 

emergency., shutdown is called from bee. bee modified the 

machine conditions of the time of return to bee to cause a return 

to emergency. shutdown! 0. This module initializes itself through 

text imbeded pointers to its linkage section; etc. and enters 
appending mode. 

Multi -programming is forced off ( tc_data$wait_ enable) . 

The apt, metering and various apte locks are forced 
"unlocked. 

The return to bee earlier stopped all of the other cpus. 
scsSprocessor is set to show this fact. 

The connect lock is forced unlocked. 

Various trouble pending, etc. flags are reset in case of 
another f ai lure. 

scs masks, etc. are set up for single (boot load) cpu 
operation. We mask down to sys_ level. 

A switch is made to the idle process, This is done by 
using scs$ idle_aptep to find the idle's apte. Its dbr is loaded. 

All other cpus are set to delete themselves, in case they 
try to start. 

The idle process has prds as its stack, A stack frame is 
pushed onto this stack by hand. 

The ast and reconfiguration locks are forcibly unlocked. 

The first external module is called. ocdcm_$esd_ reset 
resets oc_data, and the console software. 

syserr_.real$syserr_reset resets the syserr logger and the 
syserr_data segment and flags. 

io_ managers reset resets iom_data status. 

page$ esd_ reset resets its view of the disk dim. 

pc_reeover_sst recomputes the page control state. 
pageS time_ out is called. 
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disk_emergency$test_al l_dri ves_masked runs as for normal 
shutdown; but in a masked state. 

The prds is abandoned as a stack (it is reset) and the 
stack pointer set to null (idle process), The first page of 
tempi ate_pds is wired and the sdw for pds set to point to 
template_pds (hopefully a good pds). The first page is touched, 
hopefully successfully paging in the page. The stack pointers 
are then set to inzr_stkO. We then call 
w i red_ shut do wn$wired_ emergency. 

wired_shutdown sets an any_other handler and unmasks the 
processor. It makes a few checks to see if the storage system 
was enabled. If a vtoc_ buffer is in the unsafe state, its 
physical volume has its trouble count incremented. 

For each pvte, the scavenger data is reset as in a normal 
shutdown. page$reset_pvte is called. Emergency shutdown part 1 
is started. 

fsout_vol updates the rpv information on disk as for 
shutdown. 

Pages of segments are flushed from information in the core 
map entries (pcSflush). The rpv information is again written. 
This ends part one of emergency shutdown. 

vtoc_man$stabl i I ize gets vtoc buffers into shape. 

We can now call shutdown_f i I e_ system and let normal opera- 
tions carefully try to update directories and vtoces, as for a 
normal shutdown. 



MOPUIE D ESC R IPTIONS 

deactivate for demount .oil 

Qther than the flushing of pages themselves, the 
deactivation of segments (updating their directory entries and 
vtoces) performed by deactivate. for_ demount is one of the most 
important functions of shutdown. The deactivations are performed 
by hand so as not to disturb aste threads. The operation 
consists of walking down the ast hierarchy (tree) -wise, 
recognizing that each active segment has all of its parent 
directories also active. We start at the root. For each segment 
to consider, we look down its inferior list. Each look at an 
aste and an inferior element is performed with a variety of 
validity checks on the aste (within pool boundaries, parent/ son 
pointers correct, etc). .If inferiors exists, they are pushed 
onto a stack (max hierarchy depth deep) of astes to consider. 
When we push an aste with no inferiors, we consider it directly. 
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If it was a hardcore segment (deciduous) , it is removed from the 
aste list it is in and its vtoce freed. Non-hardcore segments 
have their pages flushed (pcScleanup) if they are not entry- held 
C entry- he Id segments, such as pdses had their pages flushed 
earlier and will be caught in the final flush) and their vtoces 
updated ( update_vtoce$deact) . After a segment is considered, its 
brothers are considered. When they are done, we return back to 
their parent for consideration. We proceed in this manner until 
we consider and pop the root aste off the stack. Segment control 
is now no longer active. 

demount dv.dII 

demount_pv demounts a physical volume. It starts by 
waiting for everyone to relinquish the drive; that is, no one can 
be in the middle of a physical volume operation. All segments on 
the volume sire deactivated. For the shutdown case described 
here a special deactivation is performed to avoid possible 
problems in the case of emergency shutdown. Each aste pool is 
traversed (by numerical order, not link order because of possible 
mis- I inkings) . All non-hardcore segments (except the root) are 
deactivated in-line by calling pcScleanup and update_vtoce$deact 
on the segment. We then wait for all vtoc i/o to complete to the 
disk. fsout_vol is called to update the volmap, vtoc header and 
map and the label. Finishing, we clean up the pvt entry. 

disk emergency .Dll 

To ease the burden on shutdown of drives being inoperative, 
disk_emergency$test_al l_dr i ves is called. It tests all storage 
system drives by first assuming that each one is good, then 
running disk_control$test_dr i ve. If the drive is declared inop- 
erative this time, it is marked as such with an error report 
printed. Shutdown of objects on this drive will be suspended. 

emergency shuj£djojim^aJLm 

bee, when crashed to, received the machine conditions at 
the time of the call to bee. For an emergency shutdown ( esd) , 
bee patches these to force a transfer to emergency. shutdown I 0. 
Multi -programming is forced off ( tc_data$wai t_ enable) . The apt, 
metering and various apte locks sre forced unlocked. The return 
to bee earlier stopped all of the other cpus. scsSprocessor is 
set to show this fact. The connect lock is forced unlocked. 
Various trouble pending, etc. flags sre reset in case of another 
failure. scs masks, etc. are set up for single (bootload) cpu 
operation. We mask down to sys_ level. A switch is made to the 
idle process. All other cpus are set to delete themselves, in 
case they try to start. The idle process has prds as its stack. 
A stack frame is pushed onto this stack. The ast and 
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reconfiguration locks are forcibly unlocked. ocdcm_$esd_ reset 
resets oc_data, and the console software, 
syserr_real$syserr_reset resets the syserr logger and the 
syserr_data segment and flags. io_manager$reset resets iom_data 
status. page$ esd_ reset resets its view of the disk dim. 
pc_recover_sst recomputes the page control state. pageSt ime_out 
is called. di sk_emergency$test_al l_dr i ves_masked runs as for 
normal shutdown, but in a masked state. The prds is abandoned as 
a stack (it is reset) and the stack pointer set to null (idle 
process). The first page of template_pds is wired and the sdw 
for pds set to point to template_pds (hopefully a good pds) . The 
first page is touched, hopefully successfully paging in the page. 
The stack pointers are then set to !nzr_stkO. We then call 
w i r ed_ shu t do wn$ w i r ed_ emergency . 

fsout vol .pll 

fsout_vol is called whenever a volume is demounted. This 
includes the shutdown equivalent function. It endeavors to 
update the volume map, vtoc header and map and label for a 
physical volume. It drains the vtoce stock for the disk 
( vtoc„stock_manSdrain_stock) to return those vtoces withdrawn 
previously. The vtoc map is then forced out to disk. We can 
then free the vtoc stock. We similarly drain, write out and free 
the record stock/ map. The dumper bit map is freed and updated to 
disk. The time map updated and mounted is updated in the label. 
If this is the root, this is the program that records in the 
label such useful information as the disk_table_vtocx and uid and 
the shutdown and esd state. 

scavenger .pll 

The shutdown entrypoint to scavenger is called during 
shutdown to clean up any scavenge operations in progress. It 
walks down scavenger _ data looking for live entries. For each, it 
clears the corresponding pvte fields deposi t_to_volmap, 
scav_check_ address and scavenger„block_rel which affects the 
operation of page control. 

shutdown .oil 

This is the starting driver for shutdown operations. It is 
called from hphcs_$shutdown from the Initializer command 
shutdown. It forces itself to run on the bootload cpu and it 
stmps the others. disk_emergency$test_al l_dr i ves test the drives 
before use. tc_shutdown stops and destroys the other processes, 
scavenges are stopped ( scavenger® shutdown ) . We then switch 
stacks back to inzr_stkO and proceed through shutdown within 
sw i t ch_ shu t do wn_ f i I e_ system . 
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shutdown file system. oil 

shut down_f i I e_ system is the driver for the shutdown of the 
file system. It runs on inzr_stkO. Its operations include: 
fsout_vol updating of the rpv } flushing pages of segments, 
releasing stack_0 segments for deactivation purposes^ running 
deact i vate_f or_ demounts shutdown to deactivate non- hardcore seg- 
ments and revert supervisor segments threaded into the hierarchy 
at initialization (updating directories as a result) and then 
flushing memory again (by calls to demount_pv for the various 
disks). This module keeps track of the state of operat i veness of 
drives; if any are inoperative, we just perform a final flush and 
quit; otherwise we can demount the rpv also. A final flush is 
performed to get syserr log pages out. After console i/o has 
drained, we can return to bee. 

switch shutdown file system .aim 

switch_shutdown_f i le_system is the first program in a set 
to shut down the file system. It moves us back to inzr_stkQ, the 
initialization stack for our processing. While it is fiddling 
with stack pointers, it also sets pds$stack_0_ptr and 
pds$stack_0_sdwp. On this new stack , it calls 
shutdown_f i I e_ system. 



tc shutdown. oil 



It flags the 
down state 
.enable to 0, 
in the apt, 
is called, destroying the process and finishing 



Traffic control is shutdown by tc_ shutdown, 
system as being in a shutting 
( tc_data$system_ shutdown ) . It also sets wait, 
disabling mult i -programming. For each process 
deact i vate_segs 
our task. 



wired shutdown. pll 

The module wired_ shutdown is the counterpart to shutdown in 
the esd case. It starts by setting an any_other handler and 
unmasking the processor. It makes a few checks to see if the 
storage system was enabled. If a vtoc_buffer is in the unsafe 
state, its physical volume has its trouble count incremented. 
For each pvte, the scavenger data is reset as in a normal 
shutdown. page$reset_pvte is called. Emergency shutdown part 1 
is started. fsout_vol updates the rpv information on disk as for 
shutdown. Pages of segments are flushed from information in the 
core map entries (pcSflush). The rpv information is again 
written. This ends part one of emergency shutdown. 
vtoc_man$stabl i I ize gets vtoc buffers into shape. We can now 
call shutdown_f i le_ system and let normal operations carefully try 
to update directories and vtoces, as for a normal shutdown. 
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APPENDIX A 



GLOSSARY 



abs-seg 

An abs-seg is a reserved segment number in the hardcore 
address space used to access disk or memory outside of the 
normal mechanisms. That is, they are not built by the 
normal functions that append to the storage system nor are 
they built by the functions that create segments out of the 
hardcore partition or initialization memory. Examples of 
abs-segs are segments mapped onto an area of disk to allow 
paging to be used to read/v/rite them (such a mechanism is 
used to read the config deck from disk) or segments mapped 
onto an area of memory for examination (page control does 
this to examine pages being evicted). abs-segs are managed 
( i . e. j created and deleted) , each in its own way, by a set 
of software created for the purpose; One may not use the 
standard system functions to operate upon them (such as 
segment deletion). However , the contents of the segments 
are addressed through normal mechanisms; that is, memory 
mapped abs-segs are referencable via the hardware and 
abs-segs built with an aste/page table pair in the sst are 
allowed to have page faults taken against them. 

bee 

The Boot load Command Environment within boot load Multics, 
that is, the collection of programs and facilities that make 
up a command level that allows certain critical functions to 
be performed before storage system activation occurs during 
system initialization. 

boot load Multics 

Those early parts of initialization that atro capable of 
booting bee from a cold, bare machine, including bee itself. 

cold boot 

A boot load in which the state of all hardware and peripher- 
als is unknown. In particular, the Multics file system is 
either non-existant or has been destroyed. This is also 
known as an initial boot. 
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col lection 

A "collection" is a set of programs read in as a unit that 
together perform a function during initialization. Collec- 
tions are referred to by number , starting with zero. Each 
collection depends on the mechanisms initialized by the 
collections that preceded it. As each collection finishes 
its task, some of that collection is deleted and some is 
kept j depending on the requirements of future collections. 

There are also fractionally numbered collections, which 
consist of support entities for the preceding collection- 

The division of initialization into collections is done 
based upon various restrictions imposed by the course of 
initialization. For example, since the first few collec- 
tions must run entirely within memory, restrictions on 
available memory (and the amount that can be required of a 
system) force unessential programs into later collections. 

contiguous 

A contiguous segment is one whose memory locations describe 
contiguous absolute memory locations. Most segments do not 
have this requirement; their pages may appear arbitrarily in 
memory. Certain segments, though, such as the sst_seg must 
have their locations in order, due to hardware requirements 
for placement of their contents. 

cool boot 

A boot load in which the Multics file system is on disk and 
believed to be good but in which the state of memory and 
other peripherals is unknown. In particular, boot load 
Multics is not running. The mpc's may or may not have 
firmware running in them. The system is loaded from the MST 
(tape) and initiated via iom switches. 

crash 

A failure of Multics. This may be the result of a hardware 
or software failure that causes Multics to abort itself or 
the result of an operator aborting it. A crash of Multics 
during early initialization can produce a tape dump of 
memory. Crashes after this time can be examined with bee 
utilities or saved to disk by bee and analyzed later. 

deciduous segments 

These are segments generated or read in as part of 
initialization which tare given branches in the hierarchy (by 
init_ branches) . Although they become part of the hierarchy, 
their pages remain in the hardcore partition and are 
therefore destroyed between bootloads. Examples are the 
segments in >sll and the Initializer's pds. (The name 
suggests the leaves of trees, ) 



A- 2 AN70-01 



deposit 

A page control concept, 
of free objects. 



It means to add an object to a list 



dseg 



descriptor segment (see data bases) 



dump 



A subset of Multics segments saved after a crash that can be 
examined through various dump analysis tools to determine 
the cause of the preceding crash. A dump is either a disk 
dump, a dump performed to the dump partition of disk by the 
dump facility of bee, or an "early dump" , one performed to 
tape during early initialization. 



early initialization 
Those parts of 
Mu 1 1 i cs command 
boot load Multics 
initial izat ion. 



i n i t i a I i zat i on 

level. All 
command level 



needed to 
activities 
are referred 



reach boot load 

after leaving 

to as service 



emergency shutdown 

A Multics operation, invoked by bee, that runs a subset of 
the hardcore facilities to shut down the file system (put 
the storage system into a consistent state) after a crash. 



esd 



emergency shutdown 



hardcore 
The 



supervisor of Multics, loosely defined. This is 
collection of programs and segments generated or read 
during initialization. 



in 



hproc 



process is created by a call to 
to being created through the 
Such hprocs (currently 
SyserrLogger , Daemon and MCS_T imer_ Daemon. SysDaemon) perform 
activities integral to the system operation and 
created prior to 4 and independent of, the 



A hardcore process, Such I 
create_hproc J as opposed 
answering service. 



must be 
answering service. 



i n i t segments 

Segments needed only during the course 
These are deleted after the end of 
col lection. 



of initialization, 
the last hardcore 



initial izat ion 

The action of starting Multics. 
the appropriate software modules 
and constructing the appropriate 
an event , such as someone trying 



This consists of placing 
in the appropriate places 
software tables such that 
to dial a login line, or a 



page fault occur ing, etc. will invoke the proper software 
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lest 



which will be in a position to perform the necessary 
operation. 

known segment table (see data bases) 



Ivt 



MST 



logical volume table (see data bases) 



Multics system tape 



Multics system tape 

The "tape" is the set of Multics programs that will make up 
the supervisor in un- pre- I inked form. This set of programs 
originates on a tapej some of them spend part of their lives 
in a disk partition. 

nondeci duous 

A hardcore segment not mapped into the hierarchy. These 
segments live in the hardcore partition and are known only 
by having sdw's in the hardcore address space. 

partition 

An area of a storage system diskj other than the label , 
vtoCj volume map and paging area, These areas can be 
accessed by paging mechanisms but are not used to hold pages 
of storage system segments. Hardcore segments are mapped 
onto the hardcore partition so that they may be used, and 
early initialization can runj without touching the file 
system proper. 

pro- I inking 

As the Multics supervisor is read from the MSTj the various 
modules are linked together. This operation., called 
pre-linkingj is similar to linking (binding) that occurs 
during normal service operation for user programs, except 
that it consists of running through all segments and finding 
all external references and resolving them. This is done 
during initialization for efficiencyj as well as for the 
fact that the dynamic linker cannot be used to link itself. 



ptw 



page table word 



ptwam 



page table word associative memory 



pvt 



physical volume table (see data bases) 



root physical volume 

The main disk drive. It can r,ever be deleted. 



This drive 
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is used to hold the original hardcore partition 
the partitions required by bee and is therefore 
an early point in Multics initialization. 



as we 1 1 as 
required at 



rpv 



root physical volume 



seas 



system controller addressing segment (see data bases) 



scs 



system communications segment (see data bases) 



sdw 



segment descriptor word 



sdwam 



segment descriptor word associative memory 



shutdown 

The orderly cessation of Multics service/ performed such as 
to maintain consistency of the storage system. 



sit 



segment loading table (see data bases) 



supervisor 

A collection of software needed for operation of user's 
software and support software provided for the user. This 
would include software to make disk, accessing possible, to 
provide scheduling activity, etc. The supervisor in Multics 
is referred to as "hardcore". 



temp segments 

Segments needed only 
deleted at the end of 
the next collection. 



during one collection. They are 
the major collection, before loading 



uid 



unique identifier (of a segment) 



unpaged 

A segment that is not paged under the auspices of page 
control. Such a segment has its page table either in 
unpaged. page^ tables or int. unpaged. page_ tables. Except for 
the possible presence of the breakpoint. page, these segments 
are contiguous. During early initialization, all segments 
are generated to be of this type. The program 
make. segs_ paged forms paged segments that are copies of the 
pagable initialization segments. Certain wired segments, 
though, are left unpaged. 
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In previous releases, unpaged segments were literally 
unpaged, that is., they had no page table and had the unpaged 
flag set in their sdw. Currently only f au I t_ vector , 
iom_mailbox, dn355_mai lbox, isolts_abs_seg J abs_seg and 
abs_seg1 are of this type but will receive page tables in a 
future release. 



vtoc 



The volume table of contents of a storage system volume. 
The vtoc is divided into entries (vtoce), each of which 
describes a hierarchy segment contained on that volume. 



warm boot 

A boot load in which the 
disk and believed good, 
running on the processor, 
is performed from disk. 



Multics file system is present on 

and in which boot load Multics is 

This type of boot load of Multics 



wi red 



A page, or set 
memory by page 



of pages, 
control . 



is wired if it cannot be moved from 



withdraw 

A page control concept, said of records and vtoces. 
means to remove an object from a list of free objects. 



It 
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APPENDIX B 



INITIALIZATION AND INITIALIZED DATA BASES 



This appendix 



initialization or that are 
system 



descr i bes var i ous data bases kept by 

ialization. As such, 
significant data bases within the 



»*i«.. v . „.■_« -. ~ generated by initial izat 
this list incorporates the most <=!«■-> i •£» «-»^+ h»+.» ha 






(ACTIVE INJLX 



This initialization segment corresponds to area. linker for 
initialization programs that will be paged. This area is built 
by boot I oad_ loader and segment_ 1 oader from linkage sections found 
on the MST. 



AS LINKAGE (ACTIVE 



J3GR LINKAGE.) 



This hardcore segment corresponds to area. linker for paged 
supervisor programs. It is shared across processes, and can 
therefore contain only per -system static such as initialization 
static variables (when only one process is running) or system 
wide counters, etc. The linkage areas are formed in here by the 
various MST loading programs. 



BCE DATA (BOOTLOAP. COMMAND ENVIRONMENT PATA) 

bce_data keeps information that pertains to the command 
environment features of bootload Multics. It contains entries 
that describe the main pseudo i/o switches (input, output and 
error) as well as the state of exec.com and subsystem execution. 



BOOTLOA D INFO 

bootload. info, generated initially from bootload_ inf o. cds, 
contains various information about the state and configuration of 
early initialization. It contains: the location of the bootload 
tape ( iom, controller channel, drive number and drive and 
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controller type provided by the IOM boot function); status about 
firmware loading into the boot load controller, the location of 
the rpv ( iom, controller, drive number and drive and controller 
type provided in the f ind_rp v_ subsystem dialog), the location of 
the boot load console (and type), a variety of pointers to other 
data bases, as well as the master flags indicating the presence 
of BOS and the need for a cold boot. All of this data is copied 
into sys_boot_ info during generation and during system 
initialization. Most references to this data are therefore to 
sys_boot_ info. 

bootload_ info. cds has provisions to contain si te-suppl ied 
configuration information. !f these values are provided, no 
operator queries will be needed to bring the system up. Qnly 
cold site boots or disk problems would require operator interven- 
tion during boot. It is intended that an interface will be 
provided to fill in these values, such that generate_mst could 
set the values into the segment and the checker could report 
their settings in the checker listing. 

CONFIG DECK 

Historically named, the config_deck contains the descrip- 
tion of the configuration. It contains one entry (card) for each 
iom, cpu, memory, peripheral subsystem, etc. in the configura- 
tion. It also describes various software parameters. These 
entries are referenced by programs too numerous to count. It is 
built initially by ini t_ear ly_conf ig to describe enough of the 
system to find the ripv and read in the real config_deck saved in 
a partition thereon. (If this is a cold boot, in which there 
would be no config_deck, the config_deck is entered manually or 
from the MST through the config deck editor.) After this time, 
it becomes a wired (at its initialization address) abs-seg mapped 
onto the "conf" partition. Various reconfiguration programs 
modify the entries. 

CORE MAP 

One of the page control data bases, the cor e_ map describes 
frames of memory available for paging. Each entry describes a 
page frame. When a frame is used (it has a ptw describing it), 
the disk address of the page occupying the frame is kept in the 
core_map entry. init_sst initially builds the core_map. It is 
updated to accurately describe the state of pagable memory by 
make_segs_ paged, which frees certain unpaged segments and 
col lect_f ree_core which works to find various holes between 
segments. Page control maintains these entries. 
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DBM SEG (DUMPER BIX KAE S£G) ., 

dbm_seg holds the dumper bit maps used by the volume 
dumper. "it is paged off the hardcore partition. Its 
initialization as an area was performed by dbm_ man$ i n i t . Each 
configured disk, drive has two maps here, one for the incremental 
dumper and one for the consolidated dumper. The segment starts 
with the usual lock, control information and meters. After this 
comes an area in which the bit maps are allocated. Each bit map 
consists of a bit corresponding to each vtoce on the volume in 
question. The bits indicate the need to dump the various 
segments. 

DIR LQCK SEG 

dir_lock_seg keeps track of lockings of directories and on 
processes waiting thereupon. It has a header with a lock and 
various status. Each dir_lock entry contains the uid of that 
which is locked, various flags, threads to a more recently locked 
entry; and the array of process ids for the various lockers (more 
than one only for all readers). 

PfSK POST QUEUE SEG_ 

A part of page_ control , disk_post_queue_seg is an obscure 
data base used to keep track of disk i/o postings that could not 
be made because the page table was locked at the time of i/o 
completion. 

DISK SEG 

The disk seg contains the various tables C except the pvt) 
used by disk_control and dctl to perform i/o to disks. It is 
split into the tables disk_data, disktab, chantab, devtab as well 
as the queue of disk i/o requests. disk_data contains entries 
giving the names and locations within disk_seg of the disktab 
entry for each configured disk subsystem. The disktab entry 
contains various subsystem meter s, as well as holding the queue 
entries for the subsystem. Also contained herein are the chantab 
and devtab entries for the subsystem. Each chantab entry lists a 
i/o channel to use to perform i/o to the subsystem; given as an 
io_ manager index. It also holds various per channel meters, and, 
most importantly, the dew list that performs i/o on the channel. 
The devtab entries, one per subsystem drive, describe the drives. 
This consists of status information (inoperative, etc.) as well 
as per drive statistics. 
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DM JOURNAL SEG 

A page control data base, dm_ journal _seg_ is used to keep 
track, of page synchronization operations for data management. It 
is allocated and initialized by ini t_dm_ journal_seg. It starts 
with a lock for manipulating the journal entries as well as the 
usual wait event information. Also present are information about 
the number of pages held in memory, the maximum pages held, the 
number of journals, etc. Corresponding to each aste pool is a 
structure containing a threshold and number of active, 
synchronized segments. Following this are various meters. Then 
comes the journal entries and then the page entries. Each 
journal entry contains the time stamp that determines when pages 
of the segment being held can be written (when the journal was 
written) j the number of pages held, and a relative thread to the 
list of page entries for the pages being held. A page entry 
contains the threads that make up this list, a relative pointer 
to the core map entry for the page, and a relative pointer to the 
journal entry for the page. 

DN355 DATA 

This data seg, initialized by fnp_init, contains global 
information on each configured fnp. Data for each fnp includes: 
a pointer to the hardware mailbox, pointers to the dew lists and 
the physical channel blocks (peb), the number of subchannels, the 
iom/ channel info, indexes into the peb for I si as and hslas 
Chmlcs), status of the delay queues, various flags about the 
state of fnp operations, the let (logical channel table) entry 
pointer, status of bootloading, and various counts of free 
blocks, input and output data and control transaction counts, 
etc. 



DN355 MAILBOX 

The dn355_mai Ibox is a set of mailboxes at fixed hardware 
addresses. They start with the fnp pew. Also present are 
various counts of requests and the fnp crash data. Following 
this are 8 Multics initiated sub- ma i I boxes and 4 fnp initiated 
sub- ma i I boxes. The sub- ma i I boxes describe the line for which the 
operation is being performed along with the data for that 
operat i on. 

DSEG (PESpRtPJESB. SESMEHT?. 

The descriptor segment is a hardware known data base. It 
contains a sdw (segment descriptor word) for each segment within 
a process" address space. The ultra important processor register 
dsbr (descriptor segment base register), also called the dbr, 
indicates the absolute address of the page table describing it. 
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The sdw of a segment indicates the address of the page table of 
the segment (which contain the locations of the pages of the 
segment) and other information, such as the length of the 
segment; accesses allowed, etc. dseg must be segment 0. The 
initial dseg is generated by template_slt_ and copied into dseg 
by bootload_abs_mode. Entries are added by bootload_dseg, 
get_main and make_sdw as segments are loaded from the MST. The 
generation of sdws is integrated with the creation of sit 
entries, and the allocation of memory/disk, that the sdw/ page 
tables effectively describe. 

FAULT VECTOR (FAULT ANQ. INTERRUPT VECTORS) 

This is another hardware known data base, at a fixed 
absolute memory address (0). It contains two words for each 
possible fault and interrupt. Normal ly, each entry contains a 
scu instruction, to store all machine conditions; and a tra 
instruct ionj to transfer to the code that handles the 
fault/ interrupt. These two instructions srs force executed in 
absolute mode on the processor. The entries are filled in by 
bootload_faults and in i t ial ize_f aul ts. During some phases of 
initialization; when a particular fault/ interrupt is to be 
ignored (such as a timer running out), the fault vector entry is 
set to a scu/rcu pair, which stores machine conditions and then 
reloads them, returning to the point of interruption. The scu 
and tra instructions actually perform indirect references through 
"its" pointers that are present following the interrupt vectors 
within this segment. During normal operations, only these 
pointers are changed. 



The flagbox is an area of memory, at a known address, that 
allows communication between Multics operation and bootload 
Multics. This area contains information from Multics to bootload 
Multics such as the fact that we are crashing, and here's what 
exec_com to run. Bootload Multics can pass information up when 
booting, such as being in unattended mode so that Multics will 
know how to boot. The area is examined by various programs and 
set through commands/ act i ve functions in both Multics and 
bootload Multics operation. This area is within the bee toehold. 

1 NZR S T KP (INITIALIZER SJ&CJLL 

This is the stack used by initialization and shutdown. The 
name stands for initializer stack. Originally wired, it becomes 
paged during initialization. Once the actual ring stacks are 
created and after collection 3, initialization will leave this 
stack (in init_proc). Shutdown will return to this stack for 
protection as the stack_0's are deleted. 
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[NJ UNPAGED PAGE TABLES 



The page tables for init and temp segments are kept here. 
It gets an initial value through template_slt_ and is managed by 
the various segment creation routines. Once make_ segs_ paged is 
run, no unpaged segments exists whose page tables are here. So, 
we delete this segment. The page table for this segment is 
contained within it. 



1£L££ 



DATA 



The inter -relationship between peripherals, mpc's and icm's 
is described in io_conf ig_data. It contains a set of arrays, one 
each for devices, channels, controllers and ioms. Each entry, 
besides giving the name of each instance of said objects, gives 
indexes into the other tables showing the relationship between it 
and the rest. (That is, for example, each device shows the 
physical channels going to it; each channel shows the mpc for it, 
etc. ) 

IS PAGE TABLES. 

The page tables referenced by a paged mode iom for ioi_ 
operations are found in io_page_ tables. It is a abs-wired 
segment, maintained by ioi_page_ table. It starts with a lock and 
indexes of the start of free page table lists. The header ends 
with the size and in_use flags for each page table. The page 
tables themselves are either 64 or 256 words long; each page 
table of length N starts at a mod N boundary and does not cross 
a page boundary within the segment. 

?0I PATA 

ioi_data contains information pertinent to ioi_ (the i/o 
interfacer). It holds ioi's data itself (ioi_data), as well as 
group channel and device entries for ioi handled devices. 
ioi_data contains counts of groups, channels and devices, 
reconfiguration lock, some flags, and then the channel, group and 
device entries. A channel /device group entry describes a group 
of devices available through a channel. It contains a lock, 
subsystem identifier, various flags describing the device group, 
the number of devices and some counters, A channel table entry 
describes the state of a channel. It holds status flags, the 
io_manager index for the channel, and a place for detailed 
status. A device table entry holds the wired information for an 
ioi device. Besides pointers linking it to the group and channel 
entries, it contains various status bits, workspace pointer, 
ring, process_id and event channels for communication with the 
outer ring caller, timeout and other time limits, offsets into 
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the user's workspace for status storage, and the idcw, pew, tdcw 
and status areas. 

IQM DATA 

iom_data describes data in use by i o_ manager . It starts 
with Ipw, dew, sew and status area for stopping arbitrary 
channels. This is followed by various meters, such as 
inval id_ interrupts. Following this, for each iom are various 
pieces of state inf ormat ion, on-line, paged mode, etc. It 
concludes with more meters and ending with devtab entry indices. 
For each device, a status are is followed by various flags 
(in_use), channel identification, pew, Ipw and sew, status queue 
ptr, and various times and meters. 

IQM MAILBOX 

This segment is another hardware known and fixed segment. 
It is used for communication with the various ioms. The segment 
is split into the imw area, which contains a bit per channel per 
iom per interrupt level indicating the presence of an interrupt, 
followed by the mailboxes for sending information to the ioms and 
receiving status back. 

H§T (KNOWN SEGMENT. TA&LE? 

The known segment table is a per-process segment that keeps 
track of hierarchy segments known in a process. Hardcore 
segments do not appear in the kst. The kst effectively provides 
the mapping of segment number to pathname for a process. It is 
the keeper of the description of segments that are initiated but 
not active within a process (as well as those that are active). 
The Initializer's kst is initialized by init_root_dir. It starts 
with a header providing the limits of the kst, as well as 
information such as the number of garbage collections, pointers 
to the free list, what rings are pre- linked, the 256k segment 
enable flag, a uid hash table, the kst entries and finally a 
table of private logical volumes connected to this process. Each 
kst entry contains a used list thread, the segment number of the 
segment, usage count p&r ring, uid, access information, various 
flags (directory, transparent usage, etc), an inferior count for 
directories or the Iv index for segments and the pointer to the 
containing directory entry. It is this pointer that allows the 
name of the segment to be found. Also, the segment number of the 
directory entry pointer allows us to find the kst entry for the 
containing directory, etc., allowing us to walk up the hierarchy 
to f i nd the pathname of a segment . 
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LVT (LOGICAL VQ L UM E TABIE) 

The logical volume table consists of an array of entries 
that describe the various logical volumes. It starts with a 
count of entries as well as a maximum count limit. Following 
this is a relative pointer to the first entry and a hash table 
for hashing Ivid (logical volume ids) into Ivt entries. The 
entries that follow, one per logical volume, contain a relative 
pointer to the threaded list of pvt entries for the logical 
volume, the Ivid, access class info for the volumes and then 
various flags like public and read_only. It is initialized by 
init_lvt to describe the rlv and maintained by 
I og i ca I _ vo I ume_ manager . 

NAME TABLE 

The name_ table contains a list of all of the various names 
by which the "segments in the sit (see below) are known. This 
table is used by the sit management routines but especially by 
the various pre- 1 inkers, who use it to resolve references to 
initialization modules. It is generated from template_slt_ and 
by the sit management routines, who read in the names from 
entries on the system tape. 



QC DATA 

oc_data describes data used by ocdcm_ to handle consoles. 
It starts with the required lock, version, device counts, etc. 
Various flags are kept, such as crash on recovery failure. The 
prompt, discard notice are kept here. Status pointers, times, 
etc. are followed by information on the process handling message 
re-routing. Following this are indices into queues of entries 
followed by the queues. An entry exists for priority i/o (syserr 
output, which always forces a wait until complete), one for a 
read, and 8 for queued writes. After this are meters of 
use. The segment ends with an entry for each configured 
followed by an entry for each element of a event tracing 
Each console entry provides its name, state, type, 
status, etc. Each i/o queue entry provides room for the 
output text, time queued, flags (alert, input/ output, 
status. 



pending 
obscure 
console 
queue, 
channel , 
input or 
etc) , and 



PHYSICAL RECORD BUFFER 



The physical_record_buffer 
by collection O's and collection 
i/o buffers. 



is a wired area of 
l's MST tape reading 



memory used 
routine for 



B-8 



AN70-01 



EKL (PHYSICAL VOLUME TA&LE) 

One of the disk, describing tables, the physical volume 
table contains an entry for each configured disk drive. It can 
in some ways be considered the master disk describing table in as 
much as performing i/o to a disk drive requires the pvtx C pvt 
index) of the drive (the index number of the entry in the pvt for 
that drive). The pvt entry contains the physical and logical 
volume id for the drive, various comparatively static flags about 
the drive (such as storage. system, be ing_ demounted, 
device. inoperative, etc.), information for the volume dumper and 
information about the size, fullness, vol maps and stocks (both 
record and vtoc) of the drive. This table is allocated by 
get.io.segs, and built by init_pvt. The various brothers in a 
logical volume are chained together in a list by the 
logical .volume. manager so that the vtoc.man can have a set of 
disks from which to select a target for a new segment. During 
initialization, make. sdw$ thread. hep (for ini t.root.vols) uses 
these threads (before the disk. table is accessed) to form the 
list of drives which contain hardcore partitions (those eligible 
to contain hardcore segments). 

SCAS (SYSTEM CONTROLLER ADDRESSING SEQUENT) 

This is a very curious pseudo- segment, built by seas. in it 
out of page table words generated into scs. It contains one 
pseudo- page for each memory controller (and another page for each 



individual store other than the lowest). The 
is the base address of the store/controller, 
references to it of the form n* 1 024 to form 
to controller n. Thus, instructions like 
controller register) can use this segment 
inside pr i vi leged_mode_ut) to reference the 
troller registers. 



address of the page 
This segment makes 

an absolute address 
rscr ( read system 

( as i ndeed they do 

desired system con- 



SCAVENGER DATA 

scavenger. data contains information of interest to the 
vo I ume scavenger . I ts header is i n i t i a I i zed by 
ini t_ scavenger. data. The segment starts with the usual lock and 
wait event. Following this is the pointer to the scavenger 
process table. Then come the meters. The scavenger process 
table, which follows, describes the processes performing 
scavenging operations. Each entry contains a process id of a 
scavenging process, the pvtx of the drive being scavenged, and 
indices of scavenger blocks in use. Scavenger blocks contain 
record and overflow blocks used to keep track of pages of a disk 
(its claiming vtoce and its state). 
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SCS (SYSTEM COMMUNICATIONS SEGMENT ) 

The scs is a hodge-podge of information about configuration 
and communication between active elements. It contains informa- 
tion about the scus and the cpus. It contains the cow's (connect 
operand words) needed to connect to any given cpu/iom, the 
interrupt masks used to mask/unmask, the system, the various smic 
patterns (set memory interrupt cells), instructions to clear 
associative memories and the cache, connect and reconfiguration 
locks, various trouble flags/ messages used for keeping track of 
pending communication of faults to bee, cyclic priority switch 
settings, port numbers for controllers, configuration data from 
the controllers, processor data switch values/masks, controller 
sizes, and the seas page table (see seas). 

One of the most significant initialization data bases, the 
sit describes each initialization segment. It is built initially 
from template_slt_, an aim program that not only builds the 
appropriate sit entries for collection segments, but also 
generates the dseg for collection 0. Each entry in the sit 
contains: pointers into name, table of the names and the final 
storage system pathname (and acl), if any, for the segment; 
access modes, rings, etc. for the segment; various flags used 
for generation/ loading of the segment, such as 
abs/ init/ temp/ super visor segment, wired/paged, etc.; the length 
and bit_count, etc. It is maintained by boot load_s I t_ manager and 
s I t_ manager, who build entries based on information on the MST. 
These entries are maintained so that the various pre- 1 inkers 
( boot load_l inker and pre_link_hc) can find the target segments of 
the various references. 

SSJL (SYSTEM. SEGMENT TAP.US? 

The sst (which contains the active segment table) is one of 
the most important tables in Multics. It is the keeper of active 
segments. Each active segment has an entry describing it (its 
aste) . The aste contains information used by segment control and 
communicated with page control on the state of a segment. The 
most important part of the entry is the page table words (ptws) 
describing the disk/memory location of each page. There are four 
pools of astes of different lengths to hold page tables of four 
possible maximum lengths: 4, 16, 64 and 256 ptws. The entries 
are threaded into various lists. The free entries of the various 
pools are threaded into lists. Active segments have their own 
lists. Separate lists are generated for temp and init (supervi- 
sor) segs. Aside from these threads, each aste also contains 
threads used to link segments to their parents and their trailer 
seg entry. Status information includes: the segment's uid, the 
current length, maximum length and records used, the pvtx and 
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vtocx 

pages 

and f inal ly 

rial I y bui Ids 

page controt 

control . 



of the segment (which couple with the 
of the segment), various status bits of 
the quota computation information 
this table. The page table words 
The entries themselves are 



ptws to find the 

more obscure usej 

init_sst origi- 

are maintained by 

maintained by segment 



SST NAMES 

The sst_names_ segment contains the names of paged segments 
described by" the sst. It is initialized by init_sst_name_seg 
during collection 2 and maintained by segment control only if the 
astk parm appears. It starts with information describing the 
four aste pools followed by the paged segment primary names. 

STACK fl_DAIA 

stack_0_data contains information keeping track of the ring 
stacks ( stack_0. nnn) that are shared between processes (one per 
eligible process). It is initialized by ini t_stack_0, It has a 
lock used to control threading of a pool of such stacks. Each 
entry contains a list thread., a relative pointer to the aste for 
the segment , a relative pointer to the apte for the holding 
process , and the sdw for the stack. When this stack is given to 
a process, this sdw is forced into its dsegj the acl of the stack 
is kept as a null acl. 



stock.. seg contains the record and vtoce stocks, a part of 
the reliable storage system. Whenever a new page or vtoce is 
needed for a drive, it is obtained from these stocks. The stocks 
are filled by pre- withdrawing a number of records or ytoces from 
the drive. This mechanism is used so that, upon a crash, it is 
guaranteed that any records or vtoces being created were marked 
in the record or vtoc maps as in use. This prevents re-used 
addresses. 

STR SEG (SYSTEM TRAiLER SEGMENT) 

The str_seg is a paged segment used by segment control to 
perform setfault functions. It is initialized into a list of 
f reG entries by ini t_str_seg. Each entry contains the usual 
backward and forward threads forming a list of trailers for a 
given segment (the list itself is found by a relative pointer in 
the aste for the segment). When needing to fault a segment, this 
list shows all processes containing the segment. The entry shows 
the segment number, for a process with this segment active, of 
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the segment 
that process 



and a relative pointer to the aste for the dseg of 
(which is where we need to fault the sdw) . 



SYS INFQ 

sys_info is a keeper of all sorts of information about the 
state of the system. The most important entries to 
initialization are sys_ infoS initial ization_ state, which takes on 
values of 1, 2, 3 and 4 corresponding to whether we are running 
initialization collection 1 , 2, 3 or whether we are running 
service (beyond collection 3), and sys_ inf oScol lect ion_1_ phase, 
which takes on values defined in col lect ion_1_ phases, incl . pi 1 
corresponding to running early, re_early, boot, bce_crashj ser- 
vice and crash passes through collection 1. Also included are 
key things like". the scu keeping the current time, the current 
time zone, various limits of the storage system, and some ips 
signal names and masks. The variable " max_seg_size" records the 
maximum length of a segment. This value is changed during bee 
operation to describe the maximum length of a bee paged temp 
segment. This allows various Multics routines to work without 
overflowing segments. Also in sys_info is " bce_ max_ seg_ s i ze" , 
this bee maximum segment length. This is available for any user 
ring programs who desire to limit the size of objects they 
prepare for the bee file system. 



SYS BB0T INFQ 

See bootload_ inf o, above. 



SYSERR DATA 

The syserr_data segment is 
mechanism. syserr actually just 
segment and not to the paged log 
during possible system trouble. It 
move these messages from syserr_data 



part of the syserr logging 
writes messages into this 
to avoid problems of paging 
is up to the syserr hproc to 
to the log. 



SYSERR LQG 

The paged abs-seg 
partition of disk, is used 
onto the log partition by 
involves putting syserr 



syserr_log, which describes the log 
to hold the syserr log. It is mapped 
syserr_log_ init. The syserr mechanism 
messages into syserr_data (which are 



possibly written to the console) and then waking 
hproc which copies them into the paged partition. 
so that page faults are taken by the hproc, not 
caller who may be in trouble at the time. It 
header providing the length of the segment, a 
pointers to the first and last messages placed 



up the syserr 
This is done 
by the syserr 
starts with a 
lock, relative 
there and also 
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copied out (by the answering service), the 
how full the partition can get before the 
not i f i ed to copy out the messages, the 
notification (of the answering service) 
locking. Following this are entries for 
messages. Each message is threaded with 



threshold that shows 
answering service is 

event channel for 
and the event for 

the various syserr 
the others] it has a 



time stamp, 
the message. 



id number, and the text and optional data portions of 



TP PATA 

tc_data contains information for the traffic controller. 
The most obvious entry list herein is the list of aptes (active 
process table entries). There is one apte for every process. 
The apte lists activation information for the process, such as 
its dbr, its state ( blocked/ running/ stopped/ etc. ) , various 
per-process meters (such as cpu usage), its work class, and other 
per-process scheduling parameters. Following the apt is the itt 
( inter -process transmission table), maintained by pxss (the 
traffic controller) to hold wakeups not yet received by a target 
process. The call to hcs_$wakeup (or its pxss equivalent) places 
an entry in the itt containing the target process id, the event 
channel, the message data, etc. The next call to 
hcs_$read_ events obtains the events waiting for the target 
process. Also present in tc_data is various meters (tern. incl) 
and other flags. Imbeded within this is the wet (work class 
table) which keeps track of the status of scheduling into work 
classes. tc init builds these tables (see tc_ data_ header ) . 



TC PATA HEAP5R 

This is a trick initialization segment. tc_data_ header is 
allocated wired storage by tc_init to hold the real tc_data. 
tc_data, originally build just from a eds segment and therefore 
just describing the header of tc_data, is copied in. 
for tc_data and tc_data_ header are then swapped. As 
initialization segment tc_data_ header (which describes 
in tc_data) is deleted, but tc_data (now mapped 
allocated tc_data_ header area) remains. 



The sdws 
such, the 

the read 
onto the 



The toehold is another area for Mult ics/ boot load Multics 
communication, (In particular, the flagbox is contained within 
it.) The toehold is a small program capable of getting to 
boot load Multics from a crash i ng/ shut ing down Multics service. 
(Its name is meant to suggest holding on by one's toes, in this 
case to boot load Multics.) in it_ toehold builds a dew (device 
control word) list that, when used by the toehold program, can 
write the first 512k of memory (those used by boot load Multics) 
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out to the bee partition and read in boot load Multics (saved in 
the bee partition by ini t_toehold) . The program runs in absolute 
mode. It is listed here because it contains the flagbox and the 
all important dew lists. 

TTY AREA 

Terminal control blocks (teb's) are allocated in tty_area. 
It is initialized to an area by fnp_init and managed by the 
various communication software. 

TTY BU F_ 

The tty_buf segment contains, obviously enough, the tty 
buffers used for manipulating data communicated with the fnp. It 
contains various meters of characters processed, number of calls 
to various operations, echo-negotiati on, etc., trace control 
information and timer information. Following this is the 
tty_ trace data, if present, and the tty_buf f er_block* s, split 
into free blocks and blocks with various flags and characters in 
chains, The layout of this segment into empty areas is done by 
fnp_ ini t. 



TTY TABLES 

tty_ tables is an area in which tables (conversion and 
like) are allocated. It has the usual lock and lock event, 
is initialized by fnp_init. 



the 
It 



UMPAQEP FA5 E , TA B LES 

All permanent non- per -process unpaged segments have their 
page tables in unpaged. page_ tables. The page table for this 
segment is also within it. It is generated initially by 
template_slt_ and added to by the various segment creation 
routines. The header of unpaged_page_ tables contains the abso- 
lute address extents of all hardcore segments that contain page 
tables; these are unpaged_page_ tables, int_unpaged_page„ tables 
and sst_seg. Dump analyzers look here to resolve absolute 
addresses from sdws into virtual addresses of page tables. 



VTQC,, BUFFER .SE£ 

vtoc buffers live in the vtoc_buf fer_seg. The segment is 
allocated and initialized by init_vtoc_man. It starts with the 
usual global lock and wait event. Following this are various 
parameters of the amount and usage of the vtoc buffers, including 
information about the vtoc buffer hash table. Then comes the 



B-14 



AN70-01 



vtoc_man meters. Finally comes the hash table, the vtoc buffer 
descriptors ( pvtx - vtocx info, etc.) and the vtoc buffers 
themselves. 

Wl LINKAGE (WIRED 1 N IT LINKAGE) 

This initialization segment corresponds to area. linker for 
wired initialization segments. It is built by the MST loading 
routines. 

W_LR£D_HARJlQggE„ QMA 

Another collection of data for hardcore use, this segment 
is permanent. It contains the size of a page, the amount to wire 
for temp-wiring applications, the history register control flag, 
the trap_ inva I id_ masked bit, a flag specifying the need for 
contiguous i/o buffers (if a non-paged iom exists), the debg card 
options, the fim f ault_counters and the bee abort_request flag. 

This wired hardcore segment, shared between processes, 
corresponds to area. linker for wired hardcore programs. It is 
built by the MST loading routines. 
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APPENDIX C 



MEMORY LAYOUT 



In the memory layout charts below, the starting absolute 
address and length for each data area is given (in octal). When 
a number appears in brackets ([]), this means that it is really a 
part of the segment listed above it, 



The memory layout 
loading of collection 1) 



after the 
fol lows. 



running of collection (the 



start 


length 





600 


1200 


2200 


3400 


3000 


10000 


2000 


12000 


10000 


24000 


22000 


[240001 


[4000] 


[ 24000] 


[2000] 


[300003 


[n] 


46000 


4000 


52000 


2000 


54000 


2000 


56000 


2000 


60000 


6000 


66000 


2000 


70000 


10000 


1 00000 


4000 


1 04000 


2000 


1 06000 


and up 



1777777 and down 



contents 



fau I t_ vector 

iom_mai I box 

dn355_mai I box 

bos_ toehold 

conf ig_deck 

bound_ boot I oad_ 
[(boot load Multics) toehold] 
[flagbox (overlays the toehold)] 
[ boo 1 1 oad_ ear I y_ dump] 

toehold.,, data 

unpaged_page_ tables 

i n t_ unpaged. page_ t ab I es 

breakpo i nt_page 

phy s i ca 1 _ r ecor d_ buf f er 

dseg 

name_ table 

sit 

lot 

wired segments 

f abr i cat ed segmen t s 

al I other segments 



The 
arbitrary. Hardware 
places, though; also, 
to operators. Except 
moved, 



absolute addresses of most of these segments is 

known data bases must be at their proper 

the toeholds are placed at addresses known 

for these exceptions, the segments may be 

Their addresses are contained in bootload_equs. incl . aim. 



0-1 



AN70-01 



All programs refering to this include file must be reassembled if 
these addresses are changed. Certain interdependenci es exist 
that one must be aware of. First of all, the toehold is placed 
at a mod 4 page address. physical_record_ buffer must be the 
last of the fixed memory address segments. The length of all 
segments is an integral number of pages. The two unpaged page 
tables segments must be large enough to meet the demands on themj 
refer to announce., chwm. Also, the length given for 
bound_bootload_0 must hold the text thereof. 



After collection 1 has finished, 
paged and co 1 1 ect i on 1 temp segments 
memory layout is as follows^ 



segments have been made 
have been deleted, the 



start 


length 





600 


1200 


2200 


3400 


3000 


10000 


2000 


12000 


10000 


24000 


4000 


C 24000] 


E 20003 


46000 


4000 


52000 


2000 


56000 


2000 


60000 


and up 


high mem 





contents 



fau I t_ vector 
iom_ mail box 
dn355_mai I box 
bos_ toehold 
config_deck 

toehold (boot load Multics) 
Cflagbox (overlays the toehold)] 
toehold_data 
unpaged. page_ t ab I es 
breakpo i nt_page 
paging area 
sst_seg 
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INDEX 



A 



aborting bee requests 

see bee, aborting requests 

abs-seg 3-10, 3-13, 3-16, 
3-17, 3-18, 3-19, 4-3, 
4-5, 4-16, 4-18, 6-8, A- 1 
B-2 

absolute mode 2-2 

accept. fs_ disk 6-3 

accept.rpv 6-3, 8-14 

act i ve i n i t I i nkage 
see ai.l i nkage 

active segment table 

see sst 

active supervisor linkage 
see as. I i nkage 

ai_linkage 2-7, 3-20, B- 1 

announce. chwm 3-8 

appending simulation 4-4 
see also bce_dump and 
bce_probe 

area. I inker 

see I i nkage sect i ons 

assume. con f i g_ deck. 2-7 



4-15 



aste pools 3-12, B- 1 
as_ linkage 2-7, 3-20, B- 1 

B 



bee 1-3, A-1 

aborting requests 3-18, 4-6, 

4-11 
alert messages 4-4 
area usage 4-2 
command level 4-10, 
bce_ cr ash 3-2 
boot 3-1 
crash 3- 1 
early 3-1 
command process ins 

4-1 1 
communication with Multics 

B-5 
config_deck manipulation 

4-17 
data B- 1 

disk accessing 4-3, 4-16 
error reporting 4-2, 4-8 
exec.com 4-9 
faci I it ies 4-1 
file system 3-16, 4-3, 4-16, 

4-18 
f irmware 

loading 4-10 
i/o switches 4-2, 

B-1 
initial izat ion 
invocation upon a crash 

B-1 4 



4-2, 4-9, 



4-7, 
4-1, 4-18 



4-18, 
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bee Ccont) 

machine state 5-2 
paged programs 3- 1 6 
part it ions 

creation 3-6, 3-9, 3-13 
usage 3-16, 4-1, 4-3, 
4-16, 4-17, 4-18 
probe 4-7, 4-8, 4-10, 4-11, 
4-14, 4-15 
current address 4-13, 
4-14 
question asking 4-2, 4-14 
ready messages 4-15 
reinitialize 4-10 
request processing 4-2, 4-6 
request table 4-15 
restrictions 4-3 
temp segments 4-3, 4-17 

bce_abs_seg 4-4 

bce_ alert 4-4 

bce_ alm_die 4-4 

bee. appending. si mutation 4-4, 
4-8, 4-14 

bee. check. abort 4-6 

bce_ command. processor, 4-6 

bce_ console., io 4-7 

bce_continue 4-7 

bce_ crash bee command level 
see bee, command level, 
bce_ crash 

bee. data 4-7, B- 1 

bce_die 4-7 

bce_ disp I ay_ instruct ion_ 4-7 

bce_display_scu_ 4-8 

bce_dump 4-8 

bce_error 4-8 

bce_esd 4-9 



bee. execute. command. 4-9 

bce_exec.com. 4-9 

bce_ ex ec_com_ input 4-9 

bce.fwload 3-16, 4-10 

bce_get_f lagbox 4-10 

bce_get_to_command_ level 4-10 

bce_ inst_ length_ 4-10 

bee. listen. 4-11 

bce_ I i st_requests_ 4- 1 1 

bee. map_over_ request s_ 4-11 

bce_ name, to_ segnum_ 4-11 

bce.probe 4-11 

see also bee, probe 

bce.probe. data 4- 1 4 

bce_ query 4-14 

bee. r eady 4-15 

bce_relocate_ instruction. 
4-15 

bee. request. table. 4-15 

bee. severity 4-15 

bee. shutdown. state 4-15 

bee. state 4-16 

boot 

cold 3-13, 6-4, 6-7, A- 1 

cool A- 2 

from bee 4-10 

from BOS 2-1 

from disk A-6 

from iom 2-1 

from tape A- 2 

initial A- 1 

warm A-6 
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boot bee command level 

see bee j command level, boot 

boot load command environment 
see bee 

boot load command environment 
data 
see bce_data 

boot load Multies 1-1, A- 1 

bootload_0 2-3 

bootload.l 3-8 

boot load_abs_ mode 2-2 

boot load_ console 2-4 

boot load_disk_ post 4-16 

bootload_dseg 2-4, 8-1 

boo t load_ ear ly_ dump 2-5 

boot I oad„ error 2-5 

bootload_f aults 2-5 

bootload_f i le_parti t ion 4-16, 
4-18 

bootload_f lagbox 2-6 

bootload_f orml ine 2-6 

bootload_fs_ 4-16 

bootload_f s_cmds_ 4-17 

bootload_ inf o B-1 

bootload_io 2-6 

bootload_ I inker 2-7 

boot load_ loader 2-7, 8-1 

boot load_qedx 4-17 

boot I oad_stt_ manager 2-7 



bootload_tape_f w 2-8 

boot I oad_tape_ label 2-1, 8-1 

boot_rpv_ subsystem 3-8 

boot_tape_io 3-8 

BOS 

getting to from bee 4-7 
presence of 2-7 

bound_bootload_0 2-1, 8-1 

breakpoints 3-15, 3-16, 3-17, 
4-12, 4-13, 4-14, 5-2 
see also breakpoint_page 

breakpoint„page 2-7, 3-9, 
3-16, 3-17, 3-18, A-5 
see also breakpoints 



central processor 
see cpu 

channel table entry 7-2, B-*6 

chantab B- 3 

clock 

sett i HO 3-12 

cold boot 

see boot, cold 

collection 1-1, A- 2 

collection 1-2, 2-1 
console support 2-4 
data B- 1 

error handling 2-5 
input/ output 2-6 
interrupts 2-6 
main driver 2-3 
programming in 2-2 

collection 1 1-2, 3-1 

bce_ crash pass 3-2, 3-7 
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collection 1 (cont) 
boot pass 

sequence 3-2 
boot load Multics pass 3-1 
crash pass 3-1, 3-7 
early pass 3-1 

sequence 3-5 
passes summary 3- 1 
re. early pass 3-2, 3-7 
see also bee 
service pass 3-1 

sequence 3-4 
shut pass 3-1 , 3-7 

col lection 2 1-3 
loading 3-20 
pre- I inking 3-18 
sequence 6- 1 

collection 3 1-3, 7-1 

col lection_1_phase B-12 

col lect_f ree_core 3-9 

conditions 

signal I ing 3-15 

conf iguration 
data 

see conf ig_ deck and scs 
initialization sequence 

8-1 1 
memory 8-5 

conf ig_ deck 3-10, B-2 
changes to 4-10 
editing 4-17 
initial generation 3-12 
setup 3-5 

conf ig_deck_data_ 4-17 

conf ig_deck_edit_ 3-10, 4-17 

connect operand words 3-20 

console 

collection 2^-4 
dr i ver 

see ocdcm_ 
locating 2-4 



contiguous A- 2 

cool boot 

see boot j cool 

core high water mark 3-8 

core_map 3-14, 3-17, 8-13, 
B-2 

cow 

see connect operand words 

cpu 

data B-10 
description 8-4 
initialization of data 3-20 
starting 6-9, 7-3 

crash A- 2 

early in initialization 5-1 
handler 3-1, 3-3 
handling 1-4, 5-1 
image 

access 4-4 

restarting 4-7, 5-2 
machine state 5-1 
memory saving 5-1 
memory state B- 1 3 
memory swapping B-13 

crash bee command level 
see bee, command level, 
crash 

create_root_dir 6-4 

create_root_vtoce 6-4 

cr eat e_rpv_ part i ti on 3-9 

cte 

see channel table entry 



data 

about act i ve segments B- 1 
about bee B- 1 
about boot load tape B- 1 
about collection B- 1 
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data (cont) 

about configuration 

see conf ig_deck and scs 
see j o_ conf ig_ data 
about core frames B-2 
about cpus B- 1 
about hardcore segments 

B-10 
about processes B- 1 3 
about rpv B-2 
about storage system B- 1 2 
about system controllers 

B-10 
about system state B~ 1 2 

data bases B- 1 

dbm_man 6-4 

dbm_seg 6-4, B-3 

dbr B- 4 

deactivate.. for_ demount 9-4 

deciduous segments 

see segments, deciduous 

delete_segs 3-9 

demount_pv 9-5 

deposit A- 3 

descr i ptor segment 
see dseg 

descriptor segment base 
register 
see dbr 

device table entry 7-2, B-6 

devtab B-3 

directory 

locking B-3 

dir_lock_ init 6-4, 8-14 

dir_lock_seg 6-4, B-3 



disk 

accessing 3-19, A- 1 , B-9 
i/o posting B-3 
storage system 

acceptance 6-3 

demounting 9-5 

disk queue B-3 

disktab B-3 

disk_data B-3 

disk_ emergency 9-5 

disk_post_queue_seg B-3 

disk_reader 3-9 

disk_seg 3-11, B-3 

dm_ journal _seg_ 6-6, B-4 

dn355^data B-4 

dn355_mai lbox 6-5, B-4 

dseg 2-8, 3-17, A-3, B-4 

dte 

see device table entry 

dump 

early 2-5, A-3 
to disk 4-8, A-3 
to tape A-3 

dumper bit map seg 
see dbm_seg 



early bee command level 
see bee, command level, 
early 

early initialization 
dumps 2-5 
see initialization, early 

emergency shutdown 4-9 
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emergency shutdown (cont) 
see shutdown, emergency 

emergency. shutdown 9-5 

errors 
handl ing 

in bee 3-14 

in collection 2-5 
reporting 

bee 4-8 

syserr B- 1 2 
see also failures 

esd 

see shutdown, emergency 

establ ish_conf ig_deck 3-10 

establ ish_temp_segs 4-8, 4-17 

execute interrupt cell 
register 8-8 

execute interrupt mask 
register 8-9 



f ai lures 

of boot initialization 3-2 

of Multics A- 2 

of service initialization 

3-2 

see also errors 

fast connect code 3-18 

fau I t_ vector 2-5 
see also vectors 

f i I l_vol_extents_ 3-10 

fim 5-2 

f ind_f i le_part it ion 4-18 

f ind_rpv_ subsystem 3-10 



firmware 
loading 

general mpes 3-11 

in bee 4-10 

into boot tape controller 

2-8 
non- boot load disk, mpes 

3-3, 3-16 
rpv disk mpe 3-6, 3-8 
location 4-10 

for boot tape mpe 2-3 
naming 2-3 

flagbox B-5 

management 2-6, 4-7, 4-10 

fnp_init 6-4 

fsout„vol 9-6 



G 



gates 

initialization 6-6 
1 inkages 8- 1 5 

getuid 6-5, 8-14 

get_io_segs 3-11 

get^main 3-11, 8-2 

group table entry 7-2, B-6 

gte 

see group table entry 



H 



hardcore A-3, A-5 
address space 6-1 

hardcore partition 
accessing 3-13 
allocation from 3-17, 6-3 
amount of utilization 6-3 
locating 3-13 
usage S-S, 8-2, A- 2, A- 4 
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hardcore segments 
creation 8-1 
numbering 6-6, 8-15 

hardware 

configuration 8-5 
inter- connect ion 8-3 
inter -module communication 
8-7 

hc_ 1 oad_ mpc 3-11 

hproc 6-10, A-3 

I 

idle loop 6-7 

idle process 6-9, 6-10, 8-16 

in it segments 3-9 
see segments, i n i t 

initialization A-3 
bee 4-1, 4-18 
boot fai lure 3-2 
configuration 8-3 

sequnce 8- 1 1 
directory control 6-1, 8-14 
disk, control 3-3 
early A-3 
file system 1-3 
gates 6-6 
hardware 8-3 
I inking of A- 4 
page control 1-2, 3-3, 8-13 
pl/1 environment 1-2 
rpv 3-14 
scu 3-14 

segment control 6-1, 8-14 
service failure 3-2 
storage system 6- 1 
summary 1-1 

traffic control 3-21, 6-1, 
8-16 

ini tial i zation_ state B-12 

initial izer 3- 15 



initial i zer stack 

see stack , initial i zat i on 

initial ize_faults 3-15, 6-9 

ini t ial ize_ faults. data 3-15 

init ial_error_handler 3-14 

ini t_aste_ pools 3-12 

init_bce 4-18 

ini t_ branches 6-5, A- 2 

in it_ clocks 3-12 

init_dm_journal_seg 6-6 

ini t_ear ly_conf ig 3-12 

init_empty_root 3-12 

inlt_hardcore_ gates 6-6 

init_hc_part 3-13 

init^lvt 6-6, 8-14 

ini t_part it ions 3-13, 8-14 

init_proc 7-1 

ini t_ processor 6-6, 8-16 

init_pvt 3-13, 8-13 

ini t_root_dir 6-7, 8-14 

init_root_vols 3-13, 8-13 

init_scavenger_data 6-7 

init_scu 3-14 

init_sst 3-14, 8-13 

init_sst_name_seg 6-7 

init_stack_0 6-7 

init_str_seg 6-8, 8-14 
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i n i t_ sy s_ var 6-8 

init_ toehold 5-1, 5-2, B- 1 3 

i n i t_ vo I map_ seg 6-8 

init_vol_ header 3-14 

init_vtoc_man 6-9, 8-14 

input/output 

in collection 2-6 

inter -process transmission 
table 
see itt 

interrupt mask assignment 
register 8-9 

interrupt vectors 

see vectors, interrupt 

interrupts 

collection 2-6 
mask assignment 8-9 
mask operations 8-10 
mask values 8-11 

n t_ unpaged_ page_ t ®b I es 
see segments, unpaged 

nzr_stk0 
see stack, initialization 

oi_ 7-2 

oi_data 3-11, B-6 

oi_ ini t 7-2 

oi_page_ table 7-3 

om 
description 8-4 

om_data 3-11, 3-18, B-7 

om_data_init 3-16, 8-11 

om_mai I box B-7 

io_conf ig_data 3-11, 7-2, B-6 



io_conf ig_ ini t 7-2 

i o_ page_ tab I es 

see page tables, paged mode 
iom 

itt B-13 



K 



known segment table 
see kst 

kst 6-9, 8-14, A-4, B-7 

kst_util 6-9 



let B-4 

linkage sections 2-7, 3-20, 
B-1, B-15 
hardcore gates finding 6-6 

I inking 

see pre- I inking 

loading 

of collection 2-1 

of collection 1 2-7 

of collection 2 3-20 

of collection 3 7-3 

load_disk_mpcs 3-16 

load_mst 3-16 

load_ system 7-3 

1 ock i ng 

directories 6-4 

logical channel table 
see I ct 

logical volume table 
see Ivt 
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Ivt 6-6, 8-14, A-4, B-8 







M 



ocdcm_ 3-18, 4-6, 4-7 
data B-8 



mai I boxes 

datanets B-4 
iom 3-16, B-7 

make_sdw 3-16, 3-21, 8-2 

make_segs_ paged 3-17, A- 5, 
B-6 

memory 

accessing A- 1 
al location 3-11 
allocation from sit 3-3, 

3-11, 8-2 
extent of usage 3-9 
freeing 3-9, 3-17 
layout A- 2 

after collection C- 1 

after make_segs„ paged C-2 

announcing 3-8 

placement 3-17 

required placement C- 1 
paging use 3-9 
requirements for boot load 
3-4 

move_non_perm_wired_segs 3-17 

MST 3-16, 3-20, A-4 
disk reading 3-9 
tape reading 3-8, 3-21 

mult i -programming 6-10 

Multics system tape 
see MST 



N 



name. table 2-8, B-6 

nondeciduous segments 

see segments, nondeciduous 



oc_data B-8 

see also ocdcm_, data 



page table word 
see ptw 

page table word associative 
memory 
see ptwam 

page tables 

absolute to virtual 

addresses B- 1 4 
act i ve segments B- 1 
paged mode iom 7-2, B-6 
seas B- 1 

see also unpaged page tables 
unpaged segments 

see segments, unpaged 

paging 

of bee segments 3- 16, 4-1 
of i n i t i a I i zat i on segments 
3-17 

partition A-4 

see bee, partitions 
see hardcore partition 

pathname associative memory 
6-7 

physical volume 
see disk 

physical volume table 
see pvt 

physical_record_buf fer B-8 

pll environment 
setup 3-8 
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prds_init 3-18 

pre-linking 2- 1 , A-4 
initialization A-4 
of collection 2-1 
of collection 1 2-7 
of collection 2 3-18 

pre- withdrawing B- 1 1 

pre_link_hc 3-18 

probe 

see bee, probe 4-7 

ptw A-4 

ptwam A-4, A-5 

pvt 3-11, 3-13, 8-13, A-4, 
B-9 

R 

read_disk 3-19, 8-13 

read_disk_ label 3-19, 8-13 

read_ear ly_dump_tape 2-5 

real_ initial izer 3-19 

reinitialize 4-10 

reload 7-1 

request table 

see bee, request table 

ring 1 command level 7-1 

root dir 

activation 6-7 
creation 6-4, 6-7 

root physical volume 
see rpv 

rpv A-5 

initialization 3-12 
layout 3-10 



rpv (cont) 

locating 3-10 



saf e_conf ig_deck 3-3 

salvaging 6-3, 6-5, 6-8 

save_handler_mc 5-2 

seas 3-20, A-5, B-9 

scas_init 3-20 

scavenger 9-6 

scavenger_data 6-7, B-9 

scs 3-20, A-5, B-10 

scs_and_clock_init 3-20, 8-11 

SOU 

addressing 8-6 
data B- 1 
description 8-3 
initialization of data 3-20 
register access B-9 

sdw 2-4, 8-2, A-5, B-4 
creation 3-16 

segment descriptor word 
see sdw 

segment descriptor word 
associative memory 
see sdwam 

segment loading table 
see sit 

segments 

activation information B-7 
deactivation 9-4 
deciduous 6-5, 8-3, 8-15, 

9-4, A-2 
hardcore 
data B-10 
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segments (cont) 
hardcore 

permanent 

numbering 8-15 
hierarchy 

numbering 8-15 
init 3-9, A-3 

numbering 8-15 
nondeciduous A- 4 
number i ng 

fixed 8-15 

outer r i ng B- 7 
synchronized 6-6, B-4 
temp 3-9, A-5 

numbering 8-15 
unpaged A-5, B-6, B- 1 4 

segment. loader 3-20 

setfault B-11 

shutdown 9- 1 , 9-6, A-5 
emergency 4-9, 9-3, 9-5, 
A-3 
part 1 9-2 
normal 9-7 

shutdown_fi I e. system 9-7 

shutdown. state 9-6 

sit 2-7, 2-8, 3-21, A-5, B-8, 
B-10 
memory allocation from 
see memory, allocation 
from sit 

s I t_ manager 3-21 

sst 3-14, 3-17, 8-13, 8-14, 
B-1 1 

sst_names_ 6-7, B-11 

stack 

collection 2-2 
initialization B-5 
ring 6-7, B-11 
segment number i ng 8-15 
shutdown 9-4, 9-6, 9-7, B-5 

stack 0_ data B- 1 1 



start_cpu 6-9, 8-16 

stocks 3-11, 8-13, 9-6, B-9, 
B-11 

stock. seg B- 1 1 

stop on switches 3-20 

str.seg 6-8, B-11 

supervisor 

see hardcore 

sw i tches 
i/o 

see bee, i/o switches 

sw it ch_ shutdown. f i I e_ system 
9-7 

synchronized segments 

see segments, synchronized 

syserr.data B-1 2 

syserr.log 6-9, B-1 2 

syserr.log. init 6-9 

system commun i cat i ons segment 
see scs 

system controller 
see scu 

system controller addressing 
segment 
see seas 

system segment table 
see sst 

system trailer segment 
see str.seg 

system. type 2-7 

sys.boot. i nf o B- 1 

sys.info B- 1 2 
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sys_ inf o$ bce_ max _seg_ size 
4-18 



unpaged page tables 2.-7, 2.-8, 
3-8, 3-11, 8-2 

unpaged segments 

see segments, unpaged 



tape_ reader 3-21 

tcb B-14 

tc_data 3-21, B- 1 3 

tc_data_ header B- 1 3 

tc_init 3-21, 6-10, 7-3, 8-16 

tc_ shutdown 9-7 

temp segments 3-9 
see segments, temp 

template_slt_ 2-8, 8-1, B-5, 
B-6, B-8, B-10, B-14 

terminal control blocks 
see tcb 

toehold 2-5, 5-1, 8-1, B- 1 3 
entry points 5-1 

traffic control 
data B- 1 3 
initial izat ion 

see initialization, 
traffic control 
shutdown 9-7 

tty_area 6-4, B-14 

tty_buf 6-4, B-14 

tty_tables 6-5, B-14 



U 



V 



vectors 

fault B-5 
initialization 3-15 

col lection 2 6-9 
interrupt B-5 
see also fau I t_ vector 
setup 2-5 

volmap^seg 6-8 

volume table of contents 
see vtoc 

vtoc A- 6 

accessing 6-8 
updating 9-5, 9-6 

vtoce A- 6 

accessing 6-3, 6-9, 8-14 
buffers 6-9, 9-7, B-14 
creation 

deciduous segments 6-5. 
8-3 

initial 3-14 

root dir 6-4 
deactivation 9-5 
dumper bit B-3 
scavenger B-9 
specifying number 3-13 
stock 9-6, B-9, B-11 
updating 6-8, 9-1, 9-4 
updating for partition 
creation 3-9 

vtoc_buf f er_seg B-14 



W 



uid 6-5, 8-14, A-5 

unique identifier 
see uid 



wakeups B- 1 3 
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warm boot 

see boot, warm 

wired A-6 

wired in it linkage 
see wi_l inkage 

wired supervisor linkage 
see ws_ I i nkage 

wired_hardcore_data B-15 

wired_ shutdown 9-7 

withdraw A-6 

wi_linkage 2-7, 3-20, B-15 

ws_ linkage 2-7, 3-20, B-15 
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